Hello, On Tue, Jul 24, 2018 at 03:26:40PM +0200, Michal Hocko wrote: > > 1. No matter what B, C or D sets, as long as A sets group oom, any oom > > kill inside A's subtree kills the entire subtree. > > > > 2. A's group oom policy applies iff the source of the OOM is either at > > or above A - ie. iff the OOM is system-wide or caused by memory.max > > of A. > > > > In #1, it doesn't matter what B, C or D sets, so it's kinda moot to > > discuss whether they inherit A's setting or not. A's is, if set, > > always overriding. In #2, what B, C or D sets matters if they also > > set their own memory.max, so there's no reason for them to inherit > > anything. > > > > I'm actually okay with either option. #2 is more flexible than #1 but > > given that this is a cgroup owned property which is likely to be set > > on per-application basis, #1 is likely good enough. > > > > IIRC, we did #2 in the original implementation and the simplified one > > is doing #1, right? > > No, we've been discussing #2 unless I have misunderstood something. > I find it rather non-intuitive that a property outside of the oom domain > controls the behavior inside the domain. I will keep thinking about that > though. So, one good way of thinking about this, I think, could be considering it as a scoped panic_on_oom. However panic_on_oom interacts with memcg ooms, scoping that to cgroup level should likely be how we define group oom. Thanks. -- tejun
