Re: cgroup-aware OOM killer, how to move forward

[David Rientjes <rientjes@google.com>]

On Thu, 19 Jul 2018, Roman Gushchin wrote:

> Hm, so the question is should we traverse up to the OOMing cgroup,
> or up to the first cgroup with memory.group_oom=0?
> 
> I looked at an example, and it *might* be the latter is better,
> especially if we'll make the default value inheritable.
> 
> Let's say we have a sub-tree with a workload and some control stuff.
> Workload is tolerable to OOM's (we can handle it in userspace, for
> example), but the control stuff is not.
> Then it probably makes no sense to kill the entire sub-tree,
> if a task in C has to be killed. But makes perfect sense if we
> have to kill a task in B.
> 
>   /
>   |
>   A, delegated sub-tree, group_oom=1
>  / \
> B   C, workload, group_oom=0
> ^
> some control stuff here, group_oom=1
> 
> Does this makes sense?
> 

The *only* suggestion here was that memory.group_oom take a string instead 
of a boolean value so that it can be extended later, especially if 
introducing another tunable is problematic because it clashes with 
semantics of the this one.  This is *so* trivial to do.  Anything that is 
going to care about setting up cgroup oom killing will have no problems 
writing a string instead of an integer.  I'm asking that you don't back 
the interface into a corner where extending it later is problematic.