Re: [v8 0/4] cgroup-aware OOM killer

From: Michal Hocko
Date: Mon Sep 18 2017 - 02:16:13 EST


On Fri 15-09-17 12:55:55, David Rientjes wrote:
> On Fri, 15 Sep 2017, Roman Gushchin wrote:
>
> > > But then you just enforce a structural restriction on your configuration
> > > because
> > > root
> > > / \
> > > A D
> > > /\
> > > B C
> > >
> > > is a different thing than
> > > root
> > > / | \
> > > B C D
> > >
> >
> > I actually don't have a strong argument against an approach to select
> > largest leaf or kill-all-set memcg. I think, in practice there will be
> > no much difference.
> >
> > The only real concern I have is that then we have to do the same with
> > oom_priorities (select largest priority tree-wide), and this will limit
> > an ability to enforce the priority by parent cgroup.
> >
>
> Yes, oom_priority cannot select the largest priority tree-wide for exactly
> that reason. We need the ability to control from which subtree the kill
> occurs in ancestor cgroups. If multiple jobs are allocated their own
> cgroups and they can own memory.oom_priority for their own subcontainers,
> this becomes quite powerful so they can define their own oom priorities.
> Otherwise, they can easily override the oom priorities of other cgroups.

Could you be more speicific about your usecase? What would be a
problem If we allow to only increase priority in children (like other
hierarchical controls).

--
Michal Hocko
SUSE Labs