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

[Roman Gushchin <guro@fb.com>]

On Fri, Jul 13, 2018 at 03:39:15PM -0700, David Rientjes wrote:
> On Fri, 13 Jul 2018, Roman Gushchin wrote:
> 
> > > 
> > > One of the things that I really like about cgroup v2, though, is what 
> > > appears to be an implicit, but rather apparent, goal to minimize the 
> > > number of files for each controller.  It's very clean.  So I'd suggest 
> > > that we consider memory.group_oom, or however it is named, to allow for 
> > > future development.
> > > 
> > > For example, rather than simply being binary, we'd probably want the 
> > > ability to kill all eligible processes attached directly to the victim's 
> > > mem cgroup *or* all processes attached to its subtree as well.
> > > 
> > > I'd suggest it be implemented to accept a string, "default"/"process", 
> > > "local" or "tree"/"hierarchy", or better names, to define the group oom 
> > > mechanism for the mem cgroup that is oom when one of its processes is 
> > > selected as a victim.
> > 
> > I would prefer to keep it boolean to match the simplicity of cgroup v2 API.
> > In v2 hierarchy processes can't be attached to non-leaf cgroups,
> > so I don't see the place for the 3rd meaning.
> > 
> 
> All cgroup v2 files do not need to be boolean and the only way you can add 
> a subtree oom kill is to introduce yet another file later.  Please make it 
> tristate so that you can define a mechanism of default (process only), 
> local cgroup, or subtree, and so we can avoid adding another option later 
> that conflicts with the proposed one.  This should be easy.

David, we're adding a cgroup v2 knob, and in cgroup v2 a memory cgroup
either has a sub-tree, either attached processes. So, there is no difference
between local cgroup and subtree.