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.
