Re: [PATCH v3] oom-kill: add lowmem usage aware oom kill handling

From: David Rientjes
Date: Wed Jan 27 2010 - 18:56:20 EST


On Wed, 27 Jan 2010, KAMEZAWA Hiroyuki wrote:

> Now, /proc/<pid>/oom_score and /proc/<pid>/oom_adj are used by servers.

Nonsense, there are plenty of userspace applications such as udev that
tune their own oom_adj value on their own! oom_adj is used by anyone who
wants to define oom killer priority by polarizing the badness heuristic
for certain tasks to, for example, always prefer them or completely
disable oom killing for them.

> After this patch, badness() returns different value based on given context.
> Changing format of them was an idea, but, as David said, using "RSS" values
> will show unstable oom_score. So, I didn't modify oom_score (for this time).
>

That's a seperate issue: you cannot define the baseline of the heuristic
in terms of rss because it does not allow userspace to define when a task
has become "rogue", i.e. when it is consuming far more memory than
expected, because it is a dynamic value that depends on the state of the
VM at the time of oom. That is one of the two most popular reasons for
tuning oom_adj, the other aforementioned.

The issue with using lowmem rss for CONSTRAINT_LOWMEM is that it
misinterprets oom_adj values given to tasks; users will tune their oom_adj
based on global, system-wide ooms (or use /proc/pid/oom_score to reveal
the priority) and will never understand how it affects the value of a
resident page in lowmem for GFP_DMA allocations.

> To be honest, all my work are for guys who don't tweak oom_adj based on oom_score.
> IOW, this is for usual novice people. And I don't wan't to break servers which
> depends on oom black magic currently supported.
>

Why can't you simply create your own heuristic, seperate from badness(),
for CONSTRAINT_LOWMEM? Define the criteria that you see as important in
selecting a task in that scenario and then propose it as a seperate
function, there is no requirement that we must have a single heuristic
that works for all the various oom killer constraints. It would be
entirely appropriate to ignore oom_adj in that heuristic, as well, since
its not defined for such oom conditions (OOM_DISABLE is already taken care
of in the tasklist scan and needs no further support).
--
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/