Hello, Michal. On Tue, Jul 24, 2018 at 04:43:51PM +0200, Michal Hocko wrote: > 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. Oh yeah, so, panic_on_oom is like group oom on the root cgroup, right? If 1, it treats the whole system as a single unit and kills it no matter the oom domain. If 2, it only does so if the oom is not caused by restrictions in subdomains. > 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. And we can scope it down the same way down the cgroup hierarchy. > 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. Persistent config inheritance is a big no no. It really sucks because it makes the inherited state sticky and there's no way of telling why the current setting is the way it is without knowing the past configurations of the hierarchy. We actually had a pretty bad incident due to memcg swappiness inheritance recently (top level cgroups would inherit sysctl swappiness during boot before sysctl initialized them and then post-boot it isn't clear why the settings are the way they're). Nothing in cgroup2 does persistent inheritance. If something explicit is necessary, we do .effective so that the effective config is clearly visible. > 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. That's a nack too because across delegation, from a child pov, it isn't clear why it can't change configs and it's also easy to introduce a situation where a child can lock its ancestors out of chanding their configs. Thanks. -- tejun
