VM: add would_have_oomkilled sysctl

VM: add would_have_oomkilled sysctl

[Dave Jones]

At various times in the past, we've had reports where users have been
convinced that the oomkiller was too heavy handed. I added this sysctl
mostly as a knob for them to see that the kernel really doesn't do much better
without killing something.

Signed-off-by: Dave Jones <davej@redhat.com>

diff --git a/include/linux/oom.h b/include/linux/oom.h
index 5e3aa83..79a27b4 100644
--- a/include/linux/oom.h
+++ b/include/linux/oom.h
@@ -72,5 +72,6 @@ extern struct task_struct *find_lock_task_mm(struct task_struct *p);
 extern int sysctl_oom_dump_tasks;
 extern int sysctl_oom_kill_allocating_task;
 extern int sysctl_panic_on_oom;
+extern int sysctl_would_have_oomkilled;
 #endif /* __KERNEL__*/
 #endif /* _INCLUDE_LINUX_OOM_H */
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 5abfa15..a0fed6d 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1000,6 +1000,13 @@ static struct ctl_table vm_table[] = {
 		.proc_handler	= proc_dointvec,
 	},
 	{
+		.procname	= "would_have_oomkilled",
+		.data		= &sysctl_would_have_oomkilled,
+		.maxlen		= sizeof(sysctl_would_have_oomkilled),
+		.mode		= 0644,
+		.proc_handler	= proc_dointvec,
+	},
+	{
 		.procname	= "overcommit_ratio",
 		.data		= &sysctl_overcommit_ratio,
 		.maxlen		= sizeof(sysctl_overcommit_ratio),
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 7dcca55..281ac39 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -35,6 +35,7 @@
 int sysctl_panic_on_oom;
 int sysctl_oom_kill_allocating_task;
 int sysctl_oom_dump_tasks = 1;
+int sysctl_would_have_oomkilled;
 static DEFINE_SPINLOCK(zone_scan_lock);
 
 #ifdef CONFIG_NUMA
@@ -477,6 +478,13 @@ static int oom_kill_process(struct task_struct *p, gfp_t gfp_mask, int order,
 	}
 
 	task_lock(p);
+	if (sysctl_would_have_oomkilled) {
+		printk(KERN_ERR "%s: would have killed process %d (%s), but continuing instead...\n",
+			__func__, task_pid_nr(p), p->comm);
+		task_unlock(p);
+		return 0;
+	}
+
 	pr_err("%s: Kill process %d (%s) score %d or sacrifice child\n",
 		message, task_pid_nr(p), p->comm, points);
 	task_unlock(p);
-- 
1.7.3.2

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: VM: add would_have_oomkilled sysctl

[David Rientjes]

On Fri, 26 Aug 2011, Dave Jones wrote:

> At various times in the past, we've had reports where users have been
> convinced that the oomkiller was too heavy handed. I added this sysctl
> mostly as a knob for them to see that the kernel really doesn't do much better
> without killing something.
> 

The page allocator expects that the oom killer will kill something to free 
memory so it takes a temporary timeout and then retries the allocation 
indefinitely.  We never oom kill unless we are going to retry 
indefinitely, otherwise it wouldn't be worthwhile.

That said, the only time the oom killer doesn't actually do something is 
when it detects an exiting thread that will hopefully free memory soon or 
when it detects an eligible thread that has already been oom killed and 
we're waiting for it to exit.  So this patch will result in an endless 
series of unratelimited printk's.

Not sure that's very helpful.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: VM: add would_have_oomkilled sysctl

[Dave Jones]

On Fri, Aug 26, 2011 at 11:21:20AM -0700, David Rientjes wrote:
 > On Fri, 26 Aug 2011, Dave Jones wrote:
 > 
 > > At various times in the past, we've had reports where users have been
 > > convinced that the oomkiller was too heavy handed. I added this sysctl
 > > mostly as a knob for them to see that the kernel really doesn't do much better
 > > without killing something.
 > > 
 > 
 > The page allocator expects that the oom killer will kill something to free 
 > memory so it takes a temporary timeout and then retries the allocation 
 > indefinitely.  We never oom kill unless we are going to retry 
 > indefinitely, otherwise it wouldn't be worthwhile.
 > 
 > That said, the only time the oom killer doesn't actually do something is 
 > when it detects an exiting thread that will hopefully free memory soon or 
 > when it detects an eligible thread that has already been oom killed and 
 > we're waiting for it to exit.  So this patch will result in an endless 
 > series of unratelimited printk's.
 > 
 > Not sure that's very helpful.

It's an old patch, and the oom-killer heuristics have improved since then,
as this didn't used to be the case.  Regardless, I'll just drop it from Fedora.

thanks,

	Dave

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>