On Tue 24-07-18 06:31:10, Tejun Heo wrote: > 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. So what are we going to do if we have a reasonable usecase when somebody really wants to have group kill behavior depending on the oom domain? I have hard time to imagine such a usecase but my experience tells me that users will find a way I have never thought about. -- Michal Hocko SUSE Labs
