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

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

On Mon, Nov 25, 2019 at 4:20 PM Michal Hocko <mhocko@kernel.org> wrote:
>
> On Sat 23-11-19 13:52:57, Yafang Shao wrote:
> > On Fri, Nov 22, 2019 at 6:28 PM Michal Hocko <mhocko@kernel.org> wrote:
> > >
> > > On Wed 20-11-19 20:23:54, Yafang Shao wrote:
> > > > On Wed, Nov 20, 2019 at 7:40 PM Michal Hocko <mhocko@kernel.org> wrote:
> > > > >
> > > > > On Wed 20-11-19 18:53:44, Yafang Shao wrote:
> > > > > > 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.
> > > > >
> > > > > Not really. Consider a memcg which has reached it's swap limit. The
> > > > > anonymous memory is not really reclaimable even when there is a lot of
> > > > > swap space available.
> > > > >
> > > >
> > > > The memcg swap limit is already printed in oom messages, see bellow,
> > > >
> > > > [  141.721625] memory: usage 1228800kB, limit 1228800kB, failcnt 18337
> > > > [  141.721958] swap: usage 0kB, limit 9007199254740988kB, failcnt 0
> > >
> > > But you do not have any insight on the swap limit down the oom
> > > hierarchy, do you?
> > >
> > > > > > Why not just print the memcgs which are under memory.min protection or
> > > > > > something like a total number of min protected memory ?
> > > > >
> > > > > Yes, this would likely help. But the main question really reamains, is
> > > > > this really worth it?
> > > > >
> > > >
> > > > If it doesn't cost too much, I think it is worth to do it.
> > > > As the oom path is not the critical path, so adding some print info
> > > > should not add much overhead.
> > >
> > > Generating a lot of output for the oom reports has been a real problem
> > > in many deployments.
> >
> > So why not only print non-zero counters ?
> > If some counters are 0, we don't print them, that can reduce the oom reports.
> >
> > Something like "isolated_file:0 unevictable:0 dirty:0 writeback:0
> > unstable:0" can all be removed,
> > and we consider them as zero by default.
>
> because that would make parsing more complex.
>
> > I mean we can optimze the OOM reports and only print the useful
> > information to make it not be a problem in many deployments.
>
> We can, but it would be great to have it backed by som real usecase to
> change the current behavior. I haven't heard anything so far. It is all
> about "this would be nice" without a strong justification.

Because I was told by you that "Generating a lot of output for the oom
reports has been a real problem in many deployments.".
Maybe I misunderstood you : (

Thanks
Yafang