Re: Memory overcommit
From: Vedran FuraÄ
Date: Mon Nov 02 2009 - 14:59:01 EST
David Rientjes wrote:
> 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
> 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).
Oh, well, I didn't know that. Maybe rephrasing of that part of the
output would help eliminating future misinterpretation.
>> 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.
Of course, I want algorithm that works well in all possible situations.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/