On Tue, 17 Jul 2018, Roman Gushchin wrote: > > This example is missing the usecase that I was referring to, i.e. killing > > all processes attached to a subtree because the limit on a common ancestor > > has been reached. > > > > In your example, I would think that the memory.group_oom setting of /A and > > /A/B are meaningless because there are no processes attached to them. > > > > IIUC, your proposal is to select the victim by whatever means, check the > > memory.group_oom setting of that victim, and then either kill the victim > > or all processes attached to that local mem cgroup depending on the > > setting. > > Sorry, I don't get what are you saying. > In cgroup v2 processes can't be attached to A and B. > There is no such thing as "local mem cgroup" at all. > Read the second paragraph, yes, there are no processes attached to either mem cgroup. I'm saying "group oom" can take on two different meanings: one for the behavior when the mem cgroup reaches its limit (a direct ancestor with no processes attached) and one for the mem cgrop of the process chosen for oom kill. I know that you care about the latter. My *only* suggestion was for the tunable to take a string instead of a boolean so it is extensible for future use. This seems like something so trivial.
