On Tue, Apr 14, 2020 at 3:31 AM Chris Down <chris@xxxxxxxxxxxxxx> wrote:
>
> Hi Yafang,
>
> Yafang Shao writes:
> >A recent commit 9852ae3fe529 ("mm, memcg: consider subtrees in
> >memory.events") changes the behavior of memcg events, which will
> >consider subtrees in memory.events. But oom_kill event is a special one
> >as it is used in both cgroup1 and cgroup2. In cgroup1, it is displayed
> >in memory.oom_control. The file memory.oom_control is in both root memcg
> >and non root memcg, that is different with memory.event as it only in
> >non-root memcg. That commit is okay for cgroup2, but it is not okay for
> >cgroup1 as it will cause inconsistent behavior between root memcg and
> >non-root memcg.
> >Let's recover the original behavior for cgroup1.
>
> Can you please explain the practical ramifications of this and show an
> explicitly laid out example of how this manifests, with numbers and scenarios?
> It's unclear to me that this is a real problem as is -- it may be, but there
> certainly needs to be more information.
>
Here's an example.
root memcg
/
memcg foo
/
memcg bar
Suppose there's an oom_kill in memcg bar, then the oon_kill will be
root memcg : memory.oom_control(oom_kill) 0
/
memcg foo : memory.oom_control(oom_kill) 1
/
memcg bar : memory.oom_control(oom_kill) 1
Then the user has to know whether the memcg is root or not, if it is
root memcg, then memory.oom_control(oom_kill) is its local event
only, while if it is not root memcg, then memory.oom_control(oom_kill)
includes all its descendants' oom_kill events.
Thanks
Yafang
