From: Michal Hocko <mhocko@suse.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: akpm@linux-foundation.org, guro@fb.com,
linux-mm <linux-mm@kvack.org>,
rientjes@google.com, shakeelb@google.com,
Yafang Shao <laoar.shao@gmail.com>
Subject: Re: [nacked] mm-oom-avoid-printk-iteration-under-rcu.patch removed from -mm tree
Date: Mon, 20 Apr 2020 09:33:05 +0200 [thread overview]
Message-ID: <20200420073305.GD27314@dhcp22.suse.cz> (raw)
In-Reply-To: <68371d79-dfae-e9b9-38df-dbb916607a82@i-love.sakura.ne.jp>
On Sat 18-04-20 19:13:57, Tetsuo Handa wrote:
[...]
> > For the specific issue that you are pointing out, a simple and working
> > workaround is to reduce the loglevel or disable dump_tasks. There is no
> > real reason to add ugly kluges IMHO.
>
> I do need dump_tasks() output in order to understand memory usage as of
> invocation of the OOM killer (rather than verifying whether the OOM killer
> chose appropriate OOM victim). I really do not want to reduce the loglevel
> or disable dump_tasks().
>
> You are misunderstanding the problem. Asynchronous printk() cannot solve a problem
> that printk() buffer is needlessly flooded with OOM related messages, which can
> result in loss of non OOM-related messages if console is slow and can result in
> bloating of log files if console is not slow.
I do agree with this statement. And that is the _primamry_ point why I
believe your patch doesn't solve _anything_. Why? Because it doesn't
reduce the amount of the output. You merely shift it to a different
context which adds complexity as I've mentioned already. The only thing
you really "fix" is that the potentially long taking printk is not done
from the locked oom context. This is what the async printk will address
AFAIU.
That being said, this is not the first time we are in this discussion
and I find repeating the same thing unproductive.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2020-04-20 7:33 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200131043324.wkArXTf6-%akpm@linux-foundation.org>
2020-04-17 14:33 ` Tetsuo Handa
2020-04-17 15:26 ` Michal Hocko
2020-04-18 10:13 ` Tetsuo Handa
2020-04-20 7:33 ` Michal Hocko [this message]
2020-04-22 6:40 ` Tetsuo Handa
2020-04-22 6:59 ` Michal Hocko
2020-04-23 5:34 ` Tetsuo Handa
2020-04-23 6:35 ` Yafang Shao
2020-04-23 7:34 ` Michal Hocko
2020-04-23 10:22 ` Yafang Shao
2020-04-23 11:07 ` Michal Hocko
2020-04-23 13:28 ` Tetsuo Handa
2020-04-23 14:06 ` Michal Hocko
2020-04-23 14:14 ` Tetsuo Handa
2020-04-23 14:35 ` Michal Hocko
2020-04-24 13:02 ` Steven Rostedt
2020-04-24 15:18 ` Michal Hocko
2020-04-23 15:54 ` Sergey Senozhatsky
2020-04-23 22:56 ` Tetsuo Handa
2020-04-24 0:56 ` Yafang Shao
2020-04-24 1:16 ` Tetsuo Handa
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=20200420073305.GD27314@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=guro@fb.com \
--cc=laoar.shao@gmail.com \
--cc=linux-mm@kvack.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=rientjes@google.com \
--cc=shakeelb@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