lkml.org 
[lkml]   [2010]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 4/7 -mm] oom: badness heuristic rewrite
    On Sat, 13 Feb 2010, Minchan Kim wrote:

    > > The oom killer is not the appropriate place for a kernel forkbomb policy
    > > to be implemented, you'd need to address that concern in the scheduler.
    >
    > I agree. but your's patch try to implement policy(avg rss of children < HZ)
    > in oom killer as well as detection.
    > so I pointed out that.

    That's not what's used, we detect whether a child should be included in
    the forkbomb count by checking for two traits: (i) it doesn't share an
    ->mm with the parent, otherwise it wouldn't free any memory unless the
    parent was killed as well, and (ii) its total runtime is less than a
    second since threads in forkbomb scenarios don't typically get any
    runtime. The _penalization_ is then the average rss of those children
    times how many times the count exceeds oom_forkbomb_thres.

    > I think if we want to implement it, we also consider above scenario.
    > As you said, it would be better to detect forkbom in scheduler.
    > Then, let's remove forkbomb detection in OOM killer.
    > Afterward, we can implement it in scheduler and can use it in OOM killer.
    >

    We're not enforcing a global, system-wide forkbomb policy in the oom
    killer, but we do need to identify tasks that fork a very large number of
    tasks to break ties with other tasks: in other words, it would not be
    helpful to kill an application that has been running for weeks because
    another application with the same or less memory usage has forked 1000
    children and has caused an oom condition. That unfairly penalizes the
    former application that is actually doing work.

    Again, I'd encourage you to look at this as only a slight penalization
    rather than a policy that strictly needs to be enforced. If it were
    strictly enforced, it would be a prerequisite for selection if such a task
    were to exist; in my implementation, it is part of the heuristic.

    > > That doesn't work with Rik's example of a webserver that forks a large
    > > number of threads to handle client connections.  It is _always_ better to
    > > kill a child instead of making the entire webserver unresponsive.
    >
    > In such case, admin have to handle it by oom_forkbom_thres.
    > Isn't it your goal?
    >

    oom_forkbomb_thres has a default value, which is 1000, so it should be
    enabled by default.

    > My suggestion is how handle buggy forkbomb processes which make
    > system almost hang by user's mistake. :)
    >

    I don't think you've given a clear description (or, even better, a patch)
    of your suggestion.
    \
     
     \ /
      Last update: 2010-02-15 22:57    [W:0.023 / U:0.244 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site