lkml.org 
[lkml]   [2009]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Memory overcommit
On Fri, 30 Oct 2009, Vedran Furac wrote:

> > The problem you identified in http://pastebin.com/f3f9674a0, however, is a
> > forkbomb issue where the badness score should never have been so high for
> > kdeinit4 compared to "test". That's directly proportional to adding the
> > scores of all disjoint child total_vm values into the badness score for
> > the parent and then killing the children instead.
>
> Could you explain me why ntpd invoked oom killer? Its parent is init. Or
> syslog-ng?
>

Because it attempted an order-0 GFP_USER allocation and direct reclaim
could not free any pages.

The task that invoked the oom killer is simply the unlucky task that tried
an allocation that couldn't be satisified through direct reclaim. It's
usually unrelated to the task chosen for kill unless
/proc/sys/vm/oom_kill_allocating_task is enabled (which SGI requested to
avoid excessively long tasklist scans).

> > That's the problem, not using total_vm as a baseline. Replacing that with
> > rss is not going to solve the issue and reducing the user's ability to
> > specify a rough oom priority from userspace is simply not an option.
>
> OK then, if you have a solution, I would be glad to test your patch. I
> won't care much if you don't change total_vm as a baseline. Just make
> random killing history.
>

The only randomness is in selecting a task that has a different mm from
the parent in the order of its child list. Yes, that can be addressed by
doing a smarter iteration through the children before killing one of them.

Keep in mind that a heuristic as simple as this:

- kill the task that was started most recently by the same uid, or

- kill the task that was started most recently on the system if a root
task calls the oom killer,

would have yielded perfect results for your testcase but isn't necessarily
something that we'd ever want to see.


\
 
 \ /
  Last update: 2009-10-30 20:27    [W:3.208 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site