Re: [PATCH] mm, memcg: show memcg min setting in oom messages

[Yafang Shao <laoar.shao@gmail.com>]

On Wed, Nov 20, 2019 at 6:22 PM Michal Hocko <mhocko@kernel.org> wrote:
>
> On Wed 20-11-19 03:53:05, Yafang Shao wrote:
> > A task running in a memcg may OOM because of the memory.min settings of his
> > slibing and parent. If this happens, the current oom messages can't show
> > why file page cache can't be reclaimed.
>
> min limit is not the only way to protect memory from being reclaim. The
> memory might be pinned or unreclaimable for other reasons (e.g. swap
> quota exceeded for memcg).

Both swap or unreclaimabed (unevicteable) is printed in OOM messages.
If something else can prevent the file cache being reclaimed, we'd
better show them as well.

> Besides that, there is the very same problem
> with the global OOM killer, right? And I do not expect we want to print
> all memcgs in the system (this might be hundreds).
>

I forgot the global oom...

Why not just print the memcgs which are under memory.min protection or
something like a total number of min protected memory ?

> > So it is better to show the memcg
> > min settings.
> > Let's take an example.
> >       bar    bar/memory.max = 1200M memory.min=800M
> >      /  \
> >    barA barB barA/memory.min = 800M memory.current=1G (file page cache)
> >              barB/memory.min = 0 (process in this memcg is allocating page)
> >
> > The process will do memcg reclaim if the bar/memory.max is reached. Once
> > the barA/memory.min is reached it will stop reclaiming file page caches in
> > barA, and if there is no reclaimable pages in bar and bar/barB it will
> > enter memcg OOM then.
> > After this pacch, bellow messages will be show then (only includeing the
> > relevant messages here). The lines begin with '#' are newly added info (the
> > '#' symbol is not in the original messages).
> >       memory: usage 1228800kB, limit 1228800kB, failcnt 18337
> >       ...
> >       # Memory cgroup min setting:
> >       # /bar: min 819200KB emin 0KB
> >       # /bar/barA: min 819200KB emin 819200KB
> >       # /bar/barB: min 0KB emin 0KB
> >       ...
> >       Memory cgroup stats for /bar:
> >       anon 418328576
> >       file 835756032
> >       ...
> >       unevictable 0
> >       ...
> >       oom-kill:constraint=CONSTRAINT_MEMCG..oom_memcg=/bar,task_memcg=/bar/barB
> >
> > With the new added information, we can find the memory.min in bar/barA is
> > reached and the processes in bar/barB can't reclaim file page cache from
> > bar/barA any more. While without this new added information we don't know
> > why the file page cache in bar can't be reclaimed.
>
> Well, I am not sure this is really usefull enough TBH. It doesn't give
> you the whole picture and it potentially generates a lot of output in
> the oom report. FYI we used to have a more precise break down of
> counters in memcg hierarchy, see 58cf188ed649 ("memcg, oom: provide more
> precise dump info while memcg oom happening") which later got rewritten
> by c8713d0b2312 ("mm: memcontrol: dump memory.stat during cgroup OOM")
>

At least we'd better print a total protected memory in the oom messages.

> Could you be more specific why do you really need this piece of
> information?

I have said in the commit log, that we don't know why the file cache
can't be reclaimed (when evictable is 0 and dirty is 0 as well.)

>
> > Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
> > ---
> >  mm/memcontrol.c | 15 +++++++++++++--
> >  1 file changed, 13 insertions(+), 2 deletions(-)
> --
> Michal Hocko
> SUSE Labs