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

    > What is the point of removing it, though? If it doesn't significantly
    > help some future patch, just leave it in. It's not worth breaking the
    > user/kernel interface just to remove 3 trivial lines of code.

    Because it is inconsistent at the user's expense, it has never panicked
    the machine for memory controller ooms, so why is a cpuset or mempolicy
    constrained oom conditions any different? It also panics the machine even
    on VM_FAULT_OOM which is ridiculous, the tunable is certainly not being
    used how it was documented and so given the fact that mempolicy
    constrained ooms are now much smarter with my rewrite and we never simply
    kill current unless oom_kill_quick is enabled anymore, the compulsory
    panic_on_oom == 2 mode is no longer required. Simply set all tasks
    attached to a cpuset or bound to a specific mempolicy to be OOM_DISABLE,
    the kernel need not provide confusing alternative modes to sysctls for
    this behavior. Before panic_on_oom == 2 was introduced, it would have
    only panicked the machine if panic_on_oom was set to a non-zero integer,
    defining it be something different for '2' after it has held the same
    semantics for years is inappropriate. There is just no concrete example
    that anyone can give where they want a cpuset-constrained oom to panic the
    machine when other tasks on a disjoint set of mems can continue to do
    work and the cpuset of interest cannot have its tasks set to OOM_DISABLE.

     \ /
      Last update: 2010-02-16 08:01    [W:0.021 / U:18.032 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site