On Tue 24-07-18 07:28:20, Tejun Heo wrote: > Hello, > > On Tue, Jul 24, 2018 at 04:25:54PM +0200, Michal Hocko wrote: [...] > > So can we get back to workloads and shape the semantic on top of that > > please? > > I didn't realize we were that off track. Don't both map to what we > were discussing almost perfectly? If yes, then I do not see it ;) Mostly because panic_on_oom doesn't have any scope. It is all or nothing thing. You can only control whether memcg OOMs should be considered or not because this is inherently dangerous to be the case by default. oom_group has a scope and that scope is exactly what we are trying to find a proper semantic for. And especially what to do if descendants in the hierarchy disagree with parent(s). While I do not see a sensible configuration where the scope of the OOM should define the workload is indivisible I would like to prevent from "carved in stone" semantic that couldn't be changed later. So IMHO the best option would be to simply inherit the group_oom to children. This would allow users to do their weird stuff but the default configuration would be consistent. A more restrictive variant would be to disallow changing children to mismatch the parent oom_group == 1. This would have a slight advantage that those users would get back to us with their usecases and we can either loose the restriction or explain that what they are doing is questionable and help with a more appropriate configuration. -- Michal Hocko SUSE Labs
