Hello,
On Tue, Jul 24, 2018 at 09:32:30AM +0200, Michal Hocko wrote:
> > I'd find the cgroup closest to the root which has the oom group set
> > and kill the entire subtree.
>
> Yes, this is what we have been discussing. In fact it would match the
> behavior which is still sitting in the mmotm tree where we compare
> groups.
Yeah, I'd too. Everyone except David seems to agree that that's a
good enough approach for now.
> > There's no reason to put any
> > restrictions on what each cgroup can configure. The only thing which
> > matters is is that the effective behavior is what the highest in the
> > ancestry configures, and, at the system level, it'd conceptually map
> > to panic_on_oom.
>
> Hmm, so do we inherit group_oom? If not, how do we prevent from
> unexpected behavior?
Hmm... I guess we're debating two options here. Please consider the
following hierarchy.
R
|
A (group oom == 1)
/ \
B C
|
D
1. No matter what B, C or D sets, as long as A sets group oom, any oom
kill inside A's subtree kills the entire subtree.
2. A's group oom policy applies iff the source of the OOM is either at
or above A - ie. iff the OOM is system-wide or caused by memory.max
of A.
In #1, it doesn't matter what B, C or D sets, so it's kinda moot to
discuss whether they inherit A's setting or not. A's is, if set,
always overriding. In #2, what B, C or D sets matters if they also
set their own memory.max, so there's no reason for them to inherit
anything.
I'm actually okay with either option. #2 is more flexible than #1 but
given that this is a cgroup owned property which is likely to be set
on per-application basis, #1 is likely good enough.
IIRC, we did #2 in the original implementation and the simplified one
is doing #1, right?
Thanks.
--
tejun
