blob: 75be85a7c75dc9ae521b181c1923c4e418f25516 [file] [log] [blame]
From 4964cd41cd966502c1e0c5bc929ed15c175f8218 Mon Sep 17 00:00:00 2001
From: San Mehat <>
Date: Mon, 26 Apr 2010 15:11:04 -0700
Subject: staging: android: lowmemorykiller: Don't try to kill the
same pid over and over
Patch-mainline: HEAD
Git-commit: 4964cd41cd966502c1e0c5bc929ed15c175f8218
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 <>
Signed-off-by: Greg Kroah-Hartman <>
diff --git a/drivers/staging/android/lowmemorykiller.c b/drivers/staging/android/lowmemorykiller.c
index 32314e8..8372178 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);