Re: [v3 2/6] mm, oom: cgroup-aware OOM killer
From: David Rientjes
Date: Wed Jul 12 2017 - 16:26:28 EST
On Wed, 12 Jul 2017, Roman Gushchin wrote:
> > It's a no-op if nobody sets up priorities or the system-wide sysctl is
> > disabled. Presumably, as in our model, the Activity Manager sets the
> > sysctl and is responsible for configuring the priorities if present. All
> > memcgs at the sibling level or subcontainer level remain the default if
> > not defined by the chown'd user, so this falls back to an rss model for
> > backwards compatibility.
> Hm, this is interesting...
> What I'm thinking about, is that we can introduce the following model:
> each memory cgroup has an integer oom priority value, 0 be default.
> Root cgroup priority is always 0, other cgroups can have both positive
> or negative priorities.
For our purposes we use a range of [0, 10000] for the per-process oom
priority; 10000 implies the process is not oom killable, 5000 is the
default. We use a range of [0, 9999] for the per-memcg oom priority since
memcgs cannot disable themselves from oom killing (although they could oom
disable all attached processes). We can obviously remap our priorities to
whatever we decide here, but I think we should give ourselves more room
and provide 10000 priorities at the minimum (we have 5000 true priorities
plus overlimit bias). I'm not sure that negative priorities make sense in
this model, is there a strong reason to prefer [-5000, 5000] over
And, yes, the root memcg remains a constant oom priority and is never
> During OOM victim selection we compare cgroups on each hierarchy level
> based on priority and size, if there are several cgroups with equal priority.
> Per-task oom_score_adj will affect task selection inside a cgroup if
> oom_kill_all_tasks is not set. -1000 special value will also completely
> protect a task from being killed, if only oom_kill_all_tasks is not set.
If there are several cgroups of equal priority, we prefer the one that was
created the most recently just to avoid losing work that has been done for
a long period of time. But the key in this proposal is that we _always_
continue to iterate the memcg hierarchy until we find a process attached
to a memcg with the lowest priority relative to sibling cgroups, if any.
To adapt your model to this proposal, memory.oom_kill_all_tasks would only
be effective if there are no descendant memcgs. In that case, iteration
stops anyway and in my model we kill the process with the lowest
per-process priority. This could trivially check
memory.oom_kill_all_tasks and kill everything, and I'm happy to support
that feature since we have had a need for it in the past as well.
We should talk about when this priority-based scoring becomes effective.
We enable it by default in our kernel, but it could be guarded with a VM
sysctl if necessary to enact a system-wide policy.