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    [W:4.636 / U:0.272 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site