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.
