From: Michal Hocko <mhocko@suse.com>
To: "Ricardo Cañuelo" <ricardo.canuelo@collabora.com>
Cc: akpm@linux-foundation.org, kernel@collabora.com, hch@lst.de,
guro@fb.com, rientjes@google.com, mcgrof@kernel.org,
keescook@chromium.org, yzaikin@google.com, linux-mm@kvack.org,
sergey.senozhatsky@gmail.com, pmladek@suse.com,
rostedt@goodmis.org
Subject: Re: [PATCH] mm, oom: enable rate-limiting controls for oom dumps
Date: Tue, 13 Oct 2020 13:56:43 +0200 [thread overview]
Message-ID: <20201013115643.GM29725@dhcp22.suse.cz> (raw)
In-Reply-To: <20201013092339.225lb62rs7jwfzd6@rcn-XPS-13-9360>
On Tue 13-10-20 11:23:39, Ricardo Cañuelo wrote:
> Hi Michal,
>
> Thanks for reviewing the patch and for your suggestions:
>
> On lun 12-10-2020 17:18:04, Michal Hocko wrote:
> > How does controling burst and interval solve the problem? Btw. this
> > should be a part of the changelog which should explain not only what but
> > also why the change is needed.
> >
> > It is true that the oom report can generate a lot of output. This is
> > something that is brought up for quite some time. The largest part of
> > the output tends to be the list of tasks and this seems to be the case
> > for you as well. Is the list of tasks so important that you need to have
> > it in the log? If not you can simply disable this part of the log
> > altogether by /proc/sys/vm/oom_dump_tasks.
>
> That could be another way to mitigate the problem, although losing some
> information. I'll try to come up with a better alternative.
Yes, but there is no way around this without losing information. You are
either losing whole reports or a very noisy part of a report. I consider
the first option to be worse because eligible tasks list is useful only
very seldom.
Another aspect of the problem is effectivelly broken rate limiting
because of the way how it is implemented. That is something worth
looking into IMHO.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2020-10-13 11:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-09 9:30 [PATCH] mm, oom: enable rate-limiting controls for oom dumps Ricardo Cañuelo
2020-10-12 15:18 ` Michal Hocko
2020-10-13 9:23 ` Ricardo Cañuelo
2020-10-13 11:56 ` Michal Hocko [this message]
2020-10-12 15:22 ` Petr Mladek
2020-10-12 15:41 ` Michal Hocko
2020-10-13 0:40 ` Tetsuo Handa
2020-10-13 7:25 ` Michal Hocko
2020-10-13 9:02 ` Petr Mladek
2020-10-13 10:46 ` Tetsuo Handa
2020-10-15 13:05 ` Petr Mladek
2020-10-13 9:18 ` Ricardo Cañuelo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201013115643.GM29725@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=guro@fb.com \
--cc=hch@lst.de \
--cc=keescook@chromium.org \
--cc=kernel@collabora.com \
--cc=linux-mm@kvack.org \
--cc=mcgrof@kernel.org \
--cc=pmladek@suse.com \
--cc=ricardo.canuelo@collabora.com \
--cc=rientjes@google.com \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky@gmail.com \
--cc=yzaikin@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).