summaryrefslogtreecommitdiff
path: root/drivers/staging
diff options
context:
space:
mode:
authorSan Mehat <san@google.com>2010-04-26 15:11:04 -0700
committerColin Cross <ccross@android.com>2010-09-29 17:49:33 -0700
commitfdcec72817775d290c381cc0d7da12c10fca3a11 (patch)
tree03b5cc47fbc1274182e28f26339a83c28d72bb59 /drivers/staging
parent3c455b77679043674d53e2060787ad92ed3eb9db (diff)
lowmemorykiller: Don't try to kill the same pid over and over
Under certain circumstances, a process can take awhile to handle a sig-kill (especially if it's in a scheduler group with a very low share ratio). When this occurs, lowmemkiller returns to vmscan indicating the process memory has been freed - even though the process is still waiting to die. Since the memory hasn't actually freed, lowmemkiller is called again shortly after, and picks the same process to die; regardless of the fact that it has already been 'scheduled' to die and the memory has already been reported to vmscan as having been freed. Solution is to check fatal_signal_pending() on the selected task, and if it's already pending destruction return; indicating to vmscan that no resources were freed on this pass. Signed-off-by: San Mehat <san@google.com>
Diffstat (limited to 'drivers/staging')
-rw-r--r--drivers/staging/android/lowmemorykiller.c6
1 files changed, 6 insertions, 0 deletions
diff --git a/drivers/staging/android/lowmemorykiller.c b/drivers/staging/android/lowmemorykiller.c
index 32314e85e2b7..83721786dead 100644
--- a/drivers/staging/android/lowmemorykiller.c
+++ b/drivers/staging/android/lowmemorykiller.c
@@ -133,6 +133,12 @@ static int lowmem_shrink(int nr_to_scan, gfp_t gfp_mask)
p->pid, p->comm, oom_adj, tasksize);
}
if (selected) {
+ if (fatal_signal_pending(selected)) {
+ pr_warning("process %d is suffering a slow death\n",
+ selected->pid);
+ read_unlock(&tasklist_lock);
+ return rem;
+ }
lowmem_print(1, "send sigkill to %d (%s), adj %d, size %d\n",
selected->pid, selected->comm,
selected_oom_adj, selected_tasksize);