lkml.org 
[lkml]   [2010]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 5/7 -mm] oom: replace sysctls with quick mode
    On Fri, 12 Feb 2010, KAMEZAWA Hiroyuki wrote:

    > > Two VM sysctls, oom dump_tasks and oom_kill_allocating_task, were
    > > implemented for very large systems to avoid excessively long tasklist
    > > scans. The former suppresses helpful diagnostic messages that are
    > > emitted for each thread group leader that are candidates for oom kill
    > > including their pid, uid, vm size, rss, oom_adj value, and name; this
    > > information is very helpful to users in understanding why a particular
    > > task was chosen for kill over others. The latter simply kills current,
    > > the task triggering the oom condition, instead of iterating through the
    > > tasklist looking for the worst offender.
    > >
    > > Both of these sysctls are combined into one for use on the aforementioned
    > > large systems: oom_kill_quick. This disables the now-default
    > > oom_dump_tasks and kills current whenever the oom killer is called.
    > >
    > > The oom killer rewrite is the perfect opportunity to combine both sysctls
    > > into one instead of carrying around the others for years to come for
    > > nothing else than legacy purposes.
    > >
    > > Signed-off-by: David Rientjes <rientjes@google.com>
    >
    > seems reasonable..but how old these APIs are ? Replacement is ok ?
    >

    I'm not concerned about /proc/sys/vm/oom_dump_tasks because it was
    disabled by default and is now enabled by default (unless the user sets
    this new /proc/sys/vm/oom_kill_quick). So existing users of
    oom_dump_tasks will just have their write fail but identical behavior as
    before.

    /proc/sys/vm/oom_kill_allocating_task is different since it now requires
    enabling /proc/sys/vm/oom_kill_quick, but I think there are such few users
    (SGI originally requested it a couple years ago when we started scanning
    the tasklist for CONSTRAINT_CPUSET in 2.6.24) and the side-effect of not
    enabling it is minimal, it's just a long delay at oom kill time because
    they must scan the tasklist. Therefore, I don't see it as a major problem
    that will cause large disruptions, instead I see it as a great opportunity
    to get rid of one more sysctl without taking away functionality.

    > Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    >

    Thanks!


    \
     
     \ /
      Last update: 2010-02-12 11:01    [W:0.023 / U:0.344 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site