lkml.org 
[lkml]   [2010]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch -mm 4/9 v2] oom: remove compulsory panic_on_oom mode
On Tue, 16 Feb 2010, KAMEZAWA Hiroyuki wrote:

> > If /proc/sys/vm/panic_on_oom is set to 2, the kernel will panic
> > regardless of whether the memory allocation is constrained by either a
> > mempolicy or cpuset.
> >
> > Since mempolicy-constrained out of memory conditions now iterate through
> > the tasklist and select a task to kill, it is possible to panic the
> > machine if all tasks sharing the same mempolicy nodes (including those
> > with default policy, they may allocate anywhere) or cpuset mems have
> > /proc/pid/oom_adj values of OOM_DISABLE. This is functionally equivalent
> > to the compulsory panic_on_oom setting of 2, so the mode is removed.
> >
> > Signed-off-by: David Rientjes <rientjes@google.com>
>
> NACK. In an enviroment which depends on cluster-fail-over, this is useful
> even if in such situation.
>

You don't understand that the behavior has changed ever since
mempolicy-constrained oom conditions are now affected by a compulsory
panic_on_oom mode, please see the patch description. It's absolutely
insane for a single sysctl mode to panic the machine anytime a cpuset or
mempolicy runs out of memory and is more prone to user error from setting
it without fully understanding the ramifications than any use it will ever
do. The kernel already provides a mechanism for doing this, OOM_DISABLE.
if you want your cpuset or mempolicy to risk panicking the machine, set
all tasks that share its mems or nodes, respectively, to OOM_DISABLE.
This is no different from the memory controller being immune to such
panic_on_oom conditions, stop believing that it is the only mechanism used
in the kernel to do memory isolation.


\
 
 \ /
  Last update: 2010-02-16 01:17    [from the cache]
©2003-2011 Jasper Spaans