lkml.org 
[lkml]   [2010]   [Feb]   [12]   [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 Fri, 12 Feb 2010, Minchan Kim wrote:

> > True, that's a great example of why child tasks should be sacrificed for
> > the parent: if the oom killer is being called then we are truly overloaded
> > and there's no shame in killing excessive client connections to recover,
> > otherwise we might find the entire server becoming unresponsive. The user
> > can easily tune to /proc/sys/vm/oom_forkbomb_thres to define what
> > "excessive" is to assess the penalty, if any. I'll add that to the
> > comment if we require a second revision.
> >
>
> I am worried about opposite case.
>
> If forkbomb parent makes so many children in a short time(ex, 2000 per
> second) continuously and we kill a child continuously not parent, system
> is almost unresponsible, I think.

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.
When I've brought that up in the past, the response is that if we aren't
out of memory, then it isn't a problem. It is a problem for buggy
applications because their timeslice is now spread across an egregious
amount of tasks that they are perhaps leaking and is detrimental to their
server's performance. I'm not saying that we need to enforce a hard limit
on how many tasks a server forks, for instance, but the scheduler can
detect forkbombs much easier than the oom killer's tasklist scan by at
least indicating to us with a process flag that it is a likely forkbomb.

> I suffered from that case in LTP and no swap system.
> It might be a corner case but might happen in real.
>

If you look at the patchset overall and not just this one patch, you'll
notice that we now kill the child with the highest badness() score first,
i.e. generally the one consuming the most memory. That is radically
different than the previous behavior and should prevent the system from
becoming unresponsive. The goal is to allow the user to react to the
forkbomb rather than implement a strict detection and handling heuristic
that kills innocent servers and system daemons.

> If we make sure this task is buggy forkbomb, it would be better to kill
> it. But it's hard to make sure it's a buggy forkbomb.
>
> Could we solve this problem by following as?
> If OOM selects victim and then the one was selected victim right before
> and it's repeatable 5 times for example, then we kill the victim(buggy
> forkbom) itself not child of one. It is assumed normal forkbomb is
> controlled by admin who uses oom_forkbomb_thres well. So it doesn't
> happen selecting victim continuously above five time.
>

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 other words, doing anything in the oom killer other than slightly
penalizing these tasks and killing a child is really a non-starter because
there are too many critical use cases (we have many) that would be
unfairly biased against.


\
 
 \ /
  Last update: 2010-02-12 22:03    [W:0.158 / U:0.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site