Re: [patch 6/7] oom: move oom_adj value from task_struct tomm_struct

From: David Rientjes
Date: Tue May 05 2009 - 14:30:21 EST


On Tue, 5 May 2009, Nick Piggin wrote:

> Hmm, not particularly bad to do any of this, but I guess the way to
> do it without changing userspace APIs would be to take the lowest
> value of oomkilladj for any thread in the mm and use that.
>

Then /proc/pid/oom_adj (and, thus, what /proc/pid/oom_score reports) will
be inconsistent. In other words, it would be possible for a task to have
an oom_adj value of +15, meaning to prefer killing it above all others,
and it turns out to be immune from oom killing because it shares memory
with an OOM_DISABLE task. You could argue that's broken in userspace, but
this patchset actually makes oom_adj values a trait of the memory it
represents rather than the task itself so not only is it consistent but it
doesn't cause any surprises when your system (or memcg or cpuset) is oom.

Taking the lowest oom_adj value would also require more than one expensive
tasklist scan or an internal oom killer stack of eligible tasks to kill so
we can pop a task that shares ineligible memory and still kill a task that
has a higher priority as defined by the user.

> I guess the previous behaviour was basically quite random anyway if
> multiple threads each have different oomkilladj variables so it
> probably doesn't matter.
>

Exactly, and this is what the patchset addresses: oom_adj values become a
trait of the memory it describes and not tasks that may happen to share
it. It also fixes a livelock if the highest priority task actually can't
be killed because it shares memory with an OOM_DISABLE task.

> I don't suppose you'd ever get a significantly advanced (aka crazy)
> userspace app that would want to deliberately set *one* of its threads
> as OOM_DISABLE and others allowed to be killed, would we?
>

You could argue that's totally broken in userspace, but there's no reason
for the kernel to not expose a consistent API that describes the actual
oom priority. oomkilladj really is inappropriate as a per task value.
--
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/