Re: Memory overcommit
From: David Rientjes
Date: Tue Nov 03 2009 - 22:10:54 EST
On Wed, 4 Nov 2009, KAMEZAWA Hiroyuki wrote:
> My point and your point are differnt.
> 1. All my concern is "baseline for heuristics"
> 2. All your concern is "baseline for knob, as oom_adj"
> ok ? For selecting victim by the kernel, dynamic value is much more useful.
> Current behavior of "Random kill" and "Kill multiple processes" are too bad.
> Considering oom-killer is for what, I think "1" is more important.
> But I know what you want, so, I offers new knob which is not affected by RSS
> as I wrote in previous mail.
> As memcg is growing better, using OOM-Killer for resource control should be
> ended, I think. Maybe Fake-NUMA+cpuset is working well for google system,
> but plz consider to use memcg.
I understand what you're trying to do, and I agree with it for most
desktop systems. However, I think that admins should have a very strong
influence in what tasks the oom killer kills. It doesn't really matter if
it's via oom_adj or not, and its debatable whether an adjustment on a
static heuristic score is in our best interest in the first place. But we
must have an alternative so that our control over oom killing isn't lost.
I'd also like to open another topic for discussion if you're proposing
such sweeping changes: at what point do we allow ~__GFP_NOFAIL allocations
to fail even if order < PAGE_ALLOC_COSTLY_ORDER and defer killing
anything? We both agreed that it's not always in the best interest to
kill a task so that an allocation can succeed, so we need to define some
criteria to simply fail the allocation instead.
> Old processes are important, younger are not. But as I wrote, I'll drop
> most of patch "6". So, plz forget about this part.
> I'm interested in fork-bomb killer rather than crazy badness calculation, now.
Ok, great. Thanks.
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/