{"push_id":927819671,"size":20,"distinct_size":20,"ref":"refs/heads/lightning-cm-caf","head":"8c1dc695195204197c3892f6c976c4f9fa599c40","before":"211bc09b56e0b118a9d7bafebff09f7e0a40abef","commits":[{"sha":"0c8748c8575abe0507e3cade3248c9465187cf52","author":{"email":"b3db597eb8bb7f6a166202c1f96550c548e388c9@gmail.com","name":"nikhil18"},"message":"Revert \"LMK: fixed LMK functions after new API upgrade. nr_to_scan is out.\"\n\nThis reverts commit 82070150e26b6799bb0c25d8ace347af5702be27.","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-CAF/commits/0c8748c8575abe0507e3cade3248c9465187cf52"},{"sha":"eb7f8fab610d2474b26e1a1ca3648d2121d77c7e","author":{"email":"b3db597eb8bb7f6a166202c1f96550c548e388c9@gmail.com","name":"nikhil18"},"message":"Revert \"drivers: convert shrinkers to new count/scan API\"\n\nThis reverts commit 337f11cd2ec733698d9fe0c9cfe49a5ff4a33deb.","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-CAF/commits/eb7f8fab610d2474b26e1a1ca3648d2121d77c7e"},{"sha":"e3b0eabcaaea63247885bca0d39772f0e8d3995f","author":{"email":"b3db597eb8bb7f6a166202c1f96550c548e388c9@gmail.com","name":"nikhil18"},"message":"Revert \" staging: android: lowmemorykiller: Don't count reserved free memory\"\n\nThis reverts commit a5f76d371ac9e4badd74d2cd56b710d94c4f58a4.","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-CAF/commits/e3b0eabcaaea63247885bca0d39772f0e8d3995f"},{"sha":"ed2e5cb81809fb7e06a00f8b9743a9fee00276ec","author":{"email":"b3db597eb8bb7f6a166202c1f96550c548e388c9@gmail.com","name":"nikhil18"},"message":"Revert all the proc and resource commits in version 14","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-CAF/commits/ed2e5cb81809fb7e06a00f8b9743a9fee00276ec"},{"sha":"2185405a86e611abaf4374b3e258a6df80b730d3","author":{"email":"fdd63d6d2cf1fcca4a32e9bdba550776ff3f9f3c@motorola.com","name":"Hong-Mei Li"},"message":"staging: android: lowmemorykiller: implement task's adj rbtree\n\nBased on the current LMK implementation, LMK has to scan all processes to\nselect the correct task to kill during low memory.\nThe basic idea for the optimization is to :\nqueue all tasks with oom_score_adj priority, and then LMK just selects the\nproper task from the queue(rbtree) to kill.\n\nperformance improvement:\nthe current implementation: average time to find a task to kill : 1004us\nthe optimized implementation: average time to find a task to kill: 43us\n\nChange-Id: I4dbbdd5673314dbbdabb71c3eff0dc229ce4ea91\nSigned-off-by: Hong-Mei Li <a21834@motorola.com>\nReviewed-on: http://gerrit.pcs.mot.com/548917\nSLT-Approved: Slta Waiver <sltawvr@motorola.com>\nTested-by: Jira Key <jirakey@motorola.com>\nReviewed-by: Yi-Wei Zhao <gbjc64@motorola.com>\nSubmit-Approved: Jira Key <jirakey@motorola.com>\n\nConflicts:\n\tdrivers/staging/android/Kconfig","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-CAF/commits/2185405a86e611abaf4374b3e258a6df80b730d3"},{"sha":"5a77cdf66381f4a01d2004eee0ab1a5bbf12fb37","author":{"email":"9d4b7fec34444d4f7b5bcba52a53fb47535914f4@motorola.com","name":"Yi-wei Zhao"},"message":"staging:android:lmk: read rb tree root with spinlock\n\nthere is racing condition: after reading rb tree root, it might be changed\nby other tasks before adding new node. it can lead to rb tree corruption.\nThis patch is to avoid this race condition.\n\nChange-Id: Id86bfd133488ad4ee12cd83c9bf1d1c12ef5598f\nSigned-off-by: Yi-wei Zhao <gbjc64@motorola.com>\nReviewed-on: http://gerrit.mot.com/715645\nTested-by: Jira Key <jirakey@motorola.com>\nReviewed-by: Sheng-Zhe Zhao <a18689@motorola.com>\nSLTApproved: Christopher Fries <cfries@motorola.com>\nSubmit-Approved: Jira Key <jirakey@motorola.com>\n(cherry picked from commit 5fef19ed693fef02f84cdf879f88f19e681ae770)","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-CAF/commits/5a77cdf66381f4a01d2004eee0ab1a5bbf12fb37"},{"sha":"493f3364046f3e71c2b535f0204cece5ff7882f4","author":{"email":"fdd63d6d2cf1fcca4a32e9bdba550776ff3f9f3c@motorola.com","name":"Hong-Mei Li"},"message":"drivers:lmk: Fix double delete issue\n\nsomeone may change a process's oom_score_adj by proc fs, even though the\nprocess has exited. In that case, the task was deleted from the rb tree\nalready, and the redundant deleting would trigger rb_erase panic finally.\n\nIn this patch, we make sure to clear the node after deteting and check\nits empty status before rb_erase.\n\nChange-Id: I7628c7d21011099e796b7d366cbc142f96bb8aab\nSigned-off-by: Hong-Mei Li <a21834@motorola.com>\nReviewed-on: http://gerrit.mot.com/725306\nSLTApproved: Slta Waiver <sltawvr@motorola.com>\nSME-Granted: SME Approvals Granted\nTested-by: Jira Key <jirakey@motorola.com>\nReviewed-by: Sheng-Zhe Zhao <a18689@motorola.com>\nSubmit-Approved: Jira Key <jirakey@motorola.com>\n(cherry picked from commit 15d9d3a0f77b8ad07a69c89730f127401fa1d09b)","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-CAF/commits/493f3364046f3e71c2b535f0204cece5ff7882f4"},{"sha":"7c00a4b0b22fea71e0b9964771be6c9a2155450b","author":{"email":"fdd63d6d2cf1fcca4a32e9bdba550776ff3f9f3c@motorola.com","name":"Hong-Mei Li"},"message":"lmk: wrap the lmk code with config\n\nwrap the lmk code with CONFIG_ANDROID_LMK_ADJ_RBTREE, so that we can pass\nthe build on the products who did not enable the config.\n\nChange-Id: Ib73ba1a3a233a91bf3b32c51bacaefc41f2555d4\nSigned-off-by: Hong-Mei Li <a21834@motorola.com>\nReviewed-on: http://gerrit.mot.com/725370\nSLTApproved: Slta Waiver <sltawvr@motorola.com>\nSME-Granted: SME Approvals Granted\nTested-by: Jira Key <jirakey@motorola.com>\nReviewed-by: Sheng-Zhe Zhao <a18689@motorola.com>\nSubmit-Approved: Jira Key <jirakey@motorola.com>\n(cherry picked from commit 62800d3de4e05673766a3472e1a8c466a8e2ce7b)","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-CAF/commits/7c00a4b0b22fea71e0b9964771be6c9a2155450b"},{"sha":"7177b122e9650a2037b6be78830e53a7edec0300","author":{"email":"fdd63d6d2cf1fcca4a32e9bdba550776ff3f9f3c@motorola.com","name":"Hong-Mei Li"},"message":"staging: android: lmk: check free memory when tasks switch to background\n\nAdd more free-memory check point.\nThis patch trigger low memory killer to scan free memory when a process is moved\nto background task groups.\n\nSigned-off-by: Hong-Mei Li <a21834@motorola.com>\nReviewed-on: http://gerrit.pcs.mot.com/557973\nTested-by: Jira Key <jirakey@motorola.com>\nReviewed-by: Yi-Wei Zhao <gbjc64@motorola.com>\nSLTApproved: Yi-Wei Zhao <gbjc64@motorola.com>\nSubmit-Approved: Jira Key <jirakey@motorola.com>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-CAF/commits/7177b122e9650a2037b6be78830e53a7edec0300"},{"sha":"857eaa4e18d7093099438719046cd033a582ee0e","author":{"email":"9d4b7fec34444d4f7b5bcba52a53fb47535914f4@motorola.com","name":"Yi-wei Zhao"},"message":"staging: android: lowmemorykiller: select a new task to kill\n\nUnder certain circumstances, a process may take time to handle a SIGKILL.\nWhen lowmemkiller is called again shortly after, it would pick the same\nprocess to kill over and over, so that we cann't get free memory for long time.\n\nSolution is to check fatal_signal_pending() on the selected task, and if it's\nalready pending, select a new task to kill.\n\nSigned-off-by: Tianshui Shi <kfp634@motorola.com>\nTested-by: Jira Key <JIRAKEY@motorola.com>\nReviewed-by: Yi-Wei Zhao <gbjc64@motorola.com>\nReviewed-by: Jason Hrycay <jason.hrycay@motorola.com>\nReviewed-by: Jeffrey Carlyle <jeff.carlyle@motorola.com>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-CAF/commits/857eaa4e18d7093099438719046cd033a582ee0e"},{"sha":"767525f7f0481c19ebd41f3dce35f2eb5fa4d906","author":{"email":"f4461cfe90d9062a7e55a35647585f39eb23144b@motorola.com","name":"Yuanyuan Zhong"},"message":"staging: android: lmk: skip if killed by lmk\n\nA task can be selected to kill when it's already exiting. Sending\nsignal to the task at that state won't set TIF_SIGPENDING for it.\nAfter that, every task including threads in the exiting task itself\nrunning into lmk will compete for the mutex, then spend some time\nwaiting for the exiting task to release memory or try to send signal\nto the same task again.\nWe want the exiting task to exit as early as possible but it's slowed\ndown greatly by the mutex and waiting. Skip lmk if current thread\ngroup leader is exiting and is killed by lmk. Also delegate TIF_MEMDIE\nto current task.\n\nSigned-off-by: Yuanyuan Zhong <zyy@motorola.com>\nReviewed-on: http://gerrit.pcs.mot.com/584015\nSLTApproved: Slta Waiver <sltawvr@motorola.com>\nTested-by: Jira Key <jirakey@motorola.com>\nReviewed-by: Check Patch <CHEKPACH@motorola.com>\nReviewed-by: Klocwork kwcheck <klocwork-kwcheck@sourceforge.mot.com>\nReviewed-by: Russell Knize <rknize@motorola.com>\nSubmit-Approved: Jira Key <jirakey@motorola.com>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-CAF/commits/767525f7f0481c19ebd41f3dce35f2eb5fa4d906"},{"sha":"a3ec7050c4f9b34438f57ce3867bc9df1ccb978e","author":{"email":"f4461cfe90d9062a7e55a35647585f39eb23144b@motorola.com","name":"Yuanyuan Zhong"},"message":"staging: android: lmk: check TIF directly\n\nWhen trying to fix that lmk can't kill an exiting task\n(commit 895304e926352e0272964a421bd6271e47616ab3\n(CR) staging: android: lmk: skip if killed by lmk),\nadditional check was added for the TIF_MEMDIE flag.\nHowever the task lock has already been taken when examining\nthe task. The same helper function which tries to grab the\ntask lock again will be deadlocked.\nChange to check the thread flag of thread group leader directly.\n\nSigned-off-by: Yuanyuan Zhong <zyy@motorola.com>\nReviewed-on: http://gerrit.pcs.mot.com/587751\nSLTApproved: Slta Waiver <sltawvr@motorola.com>\nTested-by: Jira Key <jirakey@motorola.com>\nReviewed-by: Yi-Wei Zhao <gbjc64@motorola.com>\nSubmit-Approved: Jira Key <jirakey@motorola.com>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-CAF/commits/a3ec7050c4f9b34438f57ce3867bc9df1ccb978e"},{"sha":"850e3bbc64c0eb68bbc6a07857d1bd0e3d3d0f70","author":{"email":"9d4b7fec34444d4f7b5bcba52a53fb47535914f4@motorola.com","name":"Yi-wei Zhao"},"message":"staging: android: lmk: add rcu lock while test task flag\n\ntest_task_flag() need to be guarded by rcu_read_lock(), because\n\n test_task_flag()->\n   while_each_thread()->\n     next_thread()-> list_entry_rcu()\n\nSigned-off-by: Yi-wei Zhao <gbjc64@motorola.com>\nReviewed-on: http://gerrit.pcs.mot.com/608283\nSLTApproved: Slta Waiver <sltawvr@motorola.com>\nTested-by: Jira Key <jirakey@motorola.com>\nReviewed-by: Hong-Mei Li <a21834@motorola.com>\nReviewed-by: Yuanyuan Zhong <zyy@motorola.com>\nReviewed-by: Jeffrey Carlyle <jeff.carlyle@motorola.com>\nSubmit-Approved: Jira Key <jirakey@motorola.com>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-CAF/commits/850e3bbc64c0eb68bbc6a07857d1bd0e3d3d0f70"},{"sha":"e46f3dae6386441a02290b3ae842b227d92eefa8","author":{"email":"91ad7be9acbda290b813c9fa34826384a2a28465@codeaurora.org","name":"Susheel Khiani"},"message":"lowmemorykiller: Do proper NULL checks\n\nPointer other_free is getting dereferenced without\nperforming proper NULL checks which may cause issue.\nDo proper NULL checks at all points before dereferencing\nit.\n\nChange-Id: I88515703d64730e42598ab16136dcce4c18b099c\nSigned-off-by: Susheel Khiani <skhiani@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-CAF/commits/e46f3dae6386441a02290b3ae842b227d92eefa8"},{"sha":"27d351017b14b4ee87b7e9a46015c009e20f98bb","author":{"email":"1efac8fcaddebe669cb35e498dd211e17e274493@samsung.com","name":"Weijie Yang"},"message":"staging: android: lowmemorykiller: set TIF_MEMDIE before send kill sig\n\nSet TIF_MEMDIE tsk_thread flag before send kill signal to the\nselected thread. This is to fit a usual code sequence and avoid\npotential race issue.\n\nSigned-off-by: Weijie Yang <weijie.yang@samsung.com>\nAcked-by: David Rientjes <rientjes@google.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>\n\nConflicts:\n\tdrivers/staging/android/lowmemorykiller.c","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-CAF/commits/27d351017b14b4ee87b7e9a46015c009e20f98bb"},{"sha":"8a33019aee05831af9b19a6e8ef4f161494ba757","author":{"email":"1aae5ab9541d66245293c8fc1b9880f5df073631@linaro.org","name":"Anton Vorontsov"},"message":"memcg: add memory.pressure_level events\n\nWith this patch userland applications that want to maintain the\ninteractivity/memory allocation cost can use the pressure level\nnotifications.  The levels are defined like this:\n\nThe \"low\" level means that the system is reclaiming memory for new\nallocations.  Monitoring this reclaiming activity might be useful for\nmaintaining cache level.  Upon notification, the program (typically\n\"Activity Manager\") might analyze vmstat and act in advance (i.e.\nprematurely shutdown unimportant services).\n\nThe \"medium\" level means that the system is experiencing medium memory\npressure, the system might be making swap, paging out active file\ncaches, etc.  Upon this event applications may decide to further analyze\nvmstat/zoneinfo/memcg or internal memory usage statistics and free any\nresources that can be easily reconstructed or re-read from a disk.\n\nThe \"critical\" level means that the system is actively thrashing, it is\nabout to out of memory (OOM) or even the in-kernel OOM killer is on its\nway to trigger.  Applications should do whatever they can to help the\nsystem.  It might be too late to consult with vmstat or any other\nstatistics, so it's advisable to take an immediate action.\n\nThe events are propagated upward until the event is handled, i.e.  the\nevents are not pass-through.  Here is what this means: for example you\nhave three cgroups: A->B->C.  Now you set up an event listener on\ncgroups A, B and C, and suppose group C experiences some pressure.  In\nthis situation, only group C will receive the notification, i.e.  groups\nA and B will not receive it.  This is done to avoid excessive\n\"broadcasting\" of messages, which disturbs the system and which is\nespecially bad if we are low on memory or thrashing.  So, organize the\ncgroups wisely, or propagate the events manually (or, ask us to\nimplement the pass-through events, explaining why would you need them.)\n\nPerformance wise, the memory pressure notifications feature itself is\nlightweight and does not require much of bookkeeping, in contrast to the\nrest of memcg features.  Unfortunately, as of current memcg\nimplementation, pages accounting is an inseparable part and cannot be\nturned off.  The good news is that there are some efforts[1] to improve\nthe situation; plus, implementing the same, fully API-compatible[2]\ninterface for CONFIG_CGROUP_MEM_RES_CTLR=n case (e.g.  embedded) is also\na viable option, so it will not require any changes on the userland\nside.\n\n[1] http://permalink.gmane.org/gmane.linux.kernel.cgroups/6291\n[2] http://lkml.org/lkml/2013/2/21/454\n\nChange-Id: Ib7b9f7986008d423b84152e2781d0402a560c95e\n[akpm@linux-foundation.org: coding-style fixes]\n[akpm@linux-foundation.org: fix CONFIG_CGROPUPS=n warnings]\nSigned-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>\nAcked-by: Kirill A. Shutemov <kirill@shutemov.name>\nAcked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>\nCc: Tejun Heo <tj@kernel.org>\nCc: David Rientjes <rientjes@google.com>\nCc: Pekka Enberg <penberg@kernel.org>\nCc: Mel Gorman <mgorman@suse.de>\nCc: Glauber Costa <glommer@parallels.com>\nCc: Michal Hocko <mhocko@suse.cz>\nCc: Luiz Capitulino <lcapitulino@redhat.com>\nCc: Greg Thelen <gthelen@google.com>\nCc: Leonid Moiseichuk <leonid.moiseichuk@nokia.com>\nCc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>\nCc: Minchan Kim <minchan@kernel.org>\nCc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>\nCc: John Stultz <john.stultz@linaro.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n\nConflicts:\n\tmm/vmscan.c","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-CAF/commits/8a33019aee05831af9b19a6e8ef4f161494ba757"},{"sha":"7f3f5db17f2a1bc0af2ba42d9105fb1f08992497","author":{"email":"db18ceb40708dab5e9bcdbeb620f7eed18da08e5@codeaurora.org","name":"Vinayak Menon"},"message":"mm: vmpressure: allow in-kernel clients to subscribe for events\n\nCurrently, vmpressure is tied to memcg and its events are\navailable only to userspace clients. This patch removes\nthe dependency on CONFIG_MEMCG and adds a mechanism for\nin-kernel clients to subscribe for vmpressure events (in\nfact raw vmpressure values are delivered instead of vmpressure\nlevels, to provide clients more flexibility to take actions\non custom pressure levels which are not currently defined\nby vmpressure module).\n\nChange-Id: I38010f166546e8d7f12f5f355b5dbfd6ba04d587\nSigned-off-by: Vinayak Menon <vinmenon@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-CAF/commits/7f3f5db17f2a1bc0af2ba42d9105fb1f08992497"},{"sha":"cb4ddba28d5919b9f9056497d5df5ca506c5a222","author":{"email":"e7b4910f4742918f5926c991d8a2cd122ac7e295@codeaurora.org","name":"Laura Abbott"},"message":"mm: Add notifier framework for showing memory\n\nThere are many drivers in the kernel which can hold on\nto lots of memory. It can be useful to dump out all those\ndrivers at key points in the kernel. Introduct a notifier\nframework for dumping this information. When the notifiers\nare called, drivers can dump out the state of any memory\nthey may be using.\n\nChange-Id: Ifb2946964bf5d072552dd56d8d6dfdd794af6d84\nSigned-off-by: Laura Abbott <lauraa@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-CAF/commits/cb4ddba28d5919b9f9056497d5df5ca506c5a222"},{"sha":"10e92485f94db46fe39ef03c3bb7fd752ea7633e","author":{"email":"db18ceb40708dab5e9bcdbeb620f7eed18da08e5@codeaurora.org","name":"Vinayak Menon"},"message":"lowmemorykiller: adapt to vmpressure\n\nThere were issues reported, where page cache thrashing was\nobserved because of LMK not killing tasks when required,\nresulting in sluggishness and higher app launch latency.\nLMK does not kill a task for the following reasons.\n1. The free and file pages are above the LMK thresholds\n2. LMK tries to pick task with an adj level corresponding\nto current thresholds, but fails to do so because of the\nabsence of tasks in that level.\nBut sometimes it is better to kill a lower adj task, than thrashing.\nAnd there are cases where the number of file pages are huge, though\nwe dont thrash, the reclaim process becomes time consuming, since\nLMK triggers will be delayed because of higher number of file\npages. Even in such cases, when reclaim path finds it difficult\nto reclaim pages, it is better to trigger lmk to free up some memory\nfaster.\n\nThe basic idea here is to make LMK more aggressive dynamically\nwhen such a thrashing scenario is detected.\n\nTo detect thrashing, this patch uses vmpressure events.\nThe values of vmpressure upon which an action has to be taken,\nwas derived empirically.\n\nThis patch also adds tracepoints to validate this feature,\nalmk_shrink and almk_vmpressure.\n\nTwo knobs are available for the user to tune adaptive lmk\nbehaviour.\n\n/sys/module/lowmemorykiller/parameters/adaptive_lmk - Write\n1 to enable the feature, 0 to disable. By default disabled.\n\n/sys/module/lowmemorykiller/parameters/vmpressure_file_min -\nThis parameter controls the behaviour of LMK when vmpressure\nis in the range of 90-94. Adaptive lmk triggers based on number file\npages wrt vmpressure_file_min, when vmpressure is in the range of\n90-94. Usually this is a pseudo minfree value, higher than the\nhighest configured value in minfree array.\n\nSigned-off-by: Vinayak Menon <vinmenon@codeaurora.org>\n[neo: This will be enabled via userspace.]\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>\n\nConflicts:\n\tdrivers/staging/android/lowmemorykiller.c\n\nConflicts:\n\tdrivers/staging/android/lowmemorykiller.c","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-CAF/commits/10e92485f94db46fe39ef03c3bb7fd752ea7633e"},{"sha":"8c1dc695195204197c3892f6c976c4f9fa599c40","author":{"email":"fdd63d6d2cf1fcca4a32e9bdba550776ff3f9f3c@motorola.com","name":"Hong-Mei Li"},"message":"staging: android: lowmemorykiller: skip dying or exiting task\n\nUnder certain circumstances, a process may take time to handle a SIGKILL.\nWhen lowmemkiller is called again shortly after, it would pick the same\nprocess to kill over and over, so that we cann't get free memory for long\ntime. We would skip the task who has fatal_signal_pending().\n\nAlso a task can be selected to kill when it's already exiting. Sending\nsignal to the task at that state won't set TIF_SIGPENDING for it.\nAfter that, every task including threads in the exiting task itself\nrunning into lmk will compete for the mutex, then spend some time\nwaiting for the exiting task to release memory or try to send signal\nto the same task again. We skip lmk if current thread group leader is\nexiting and is killed by lmk. Also delegate TIF_MEMDIE to current task.\n\nThis is ported and mergered from below four local patches:\n    d9d2b1f141a4d4bbb94501a10282d9cd5e119b6f\n    8a57e7df00a12f35370d5edef83676f24d8e8ade\n    87656f5289168b13e94dcd2a1d678c5008b1d074\n    90f9b91c86307667572a6487b2fbdb7575c434f6\n\nChange-Id: I0bf7f59bc01549c75df365bff46fc9f7262b4300\nSigned-off-by: Hong-Mei Li <a21834@motorola.com>\nReviewed-on: http://gerrit.pcs.mot.com/625310\nSLTApproved: Slta Waiver <sltawvr@motorola.com>\nTested-by: Jira Key <jirakey@motorola.com>\nReviewed-by: Yi-Wei Zhao <gbjc64@motorola.com>\nSubmit-Approved: Jira Key <jirakey@motorola.com>","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-CAF/commits/8c1dc695195204197c3892f6c976c4f9fa599c40"}]}