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

[Michal Hocko <mhocko@kernel.org>]

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