Re: cgroup-aware OOM killer, how to move forward

[Michal Hocko <mhocko@kernel.org>]

On Tue 24-07-18 07:49:40, Tejun Heo wrote:
> Hello, Michal.
> 
> On Tue, Jul 24, 2018 at 04:43:51PM +0200, Michal Hocko wrote:
[...]
> > 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.

OK, fair points. I will keep thinking about this some more. I still
cannot shake a bad feeling about the semantic and how poor users are
going to scratch their heads what the heck is going on here. I will
follow up in other email where we are discussing both options once
I am able to sort this out myself.
-- 
Michal Hocko
SUSE Labs