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    [from the cache]
©2003-2011 Jasper Spaans