Re: Memory overcommit
From: KAMEZAWA Hiroyuki
Date: Tue Nov 03 2009 - 22:22:44 EST
On Tue, 3 Nov 2009 19:10:34 -0800 (PST)
David Rientjes <rientjes@xxxxxxxxxx> wrote:
> 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.
> > Off-topic:
> > 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'll not go too quickly, so, let's discuss and rewrite patches more, later.
I'll parepare new version in the next week. For this week, I'll post
swap accounting and improve fork-bomb detector.
> 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.
Yes, I think allocation itself (> order=0) should fail more before we finally
invoke OOM. It tends to be soft-landing rather than oom-killer.
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/