On Mon 23-07-18 08:09:29, Tejun Heo wrote: > Hello, > > On Mon, Jul 23, 2018 at 04:17:48PM +0200, Michal Hocko wrote: > > I am not sure. If you are going to delegate then you are basically > > losing control of the group_oom at A-level. Is this good? What if I > > _want_ to tear down the whole thing if it starts misbehaving because I > > do not trust it? > > > > The more I think about it the more I am concluding that we should start > > with a more contrained model and require that once parent is > > group_oom == 1 then children have to as well. If we ever find a usecase > > to require a different scheme we can weaker it later. We cannot do that > > other way around. > > > > Tejun, Johannes what do you think about that? > > I'd find the cgroup closest to the root which has the oom group set > and kill the entire subtree. Yes, this is what we have been discussing. In fact it would match the behavior which is still sitting in the mmotm tree where we compare groups. > There's no reason to put any > restrictions on what each cgroup can configure. The only thing which > matters is is that the effective behavior is what the highest in the > ancestry configures, and, at the system level, it'd conceptually map > to panic_on_oom. Hmm, so do we inherit group_oom? If not, how do we prevent from unexpected behavior? -- Michal Hocko SUSE Labs
