From: Steven Rostedt <rostedt@goodmis.org>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Petr Mladek <pmladek@suse.com>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
linux-kernel@vger.kernel.org, Dmitry Safonov <dima@arista.com>,
Michal Hocko <mhocko@suse.com>,
Yafang Shao <laoar.shao@gmail.com>
Subject: Re: [PATCH] printk: Add loglevel for "do not print to consoles".
Date: Fri, 24 Apr 2020 09:28:16 -0400 [thread overview]
Message-ID: <20200424092816.62a61b1d@gandalf.local.home> (raw)
In-Reply-To: <20200424024239.63607-1-penguin-kernel@I-love.SAKURA.ne.jp>
On Fri, 24 Apr 2020 11:42:39 +0900
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote:
> Since dump_tasks() is capable of generating thousands of printk() lines,
> it can significantly delay solving OOM situation by killing a process
> via the OOM killer. There is /proc/sys/vm/oom_dump_tasks which allows
> suppressing dump_tasks(), but those who diagnose the reason of OOM need
> dump_tasks() in order to understand memory usage as of invocation of the
> OOM killer. Therefore, setting /proc/sys/vm/oom_dump_tasks to 0 cannot be
> an option. Also, since userspace syslog daemon is likely configured not
> to save low (e.g. KERN_DEBUG) loglevels, reducing loglevel used by
> dump_tasks() cannot be an option. We want to maintain current loglevels
> in order to allow saving kernel messages to log files while we also want
> to avoid delays caused by printing to consoles due to maintaining current
> loglevels.
>
> While an attempt to make printk() asynchronous (i.e. defer printing to
> consoles) and an attempt to make printk() to print to only selected
> consoles (i.e. don't print unimportant messages to slow consoles) are
> in progress, there are printk() callers where saving to log files is
> useful for later analysis but printing to consoles for immediate
> notification makes little sense. Two examples of such printk() callers
> will be the OOM killer and memory allocation failure messages. Therefore,
> this patch introduces a loglevel KERN_NO_CONSOLES which prevents all
> consoles from printing such messages.
>
> Since both KERN_NO_CONSOLES messages and !KERN_NO_CONSOLES messages are
> stored into common printk buffer, KERN_NO_CONSOLES messages will be
> retrievable from the vmcore file even if something bad (e.g. NULL pointer
> dereference) followed. Therefore, as long as a system is configured for
> later analysis, ability to suppress printing to consoles will be useful.
> Since Dmitry Safonov is working on adding loglevel argument to
> show_stack(), we will in near future be able to control whether
> dump_stack() output is important enough to immediately print to consoles,
> by adding loglevel argument to dump_stack().
>
Please no.
What I would suggest doing is create your own buffer to store the output.
Then use the seq_buf() operations and such to print to that buffer, and
then be able to read that output from something like a debug filesystem, or
some user space daemon that will write to syslog.
I do not want 'silent' writes to the printk buffer. It's bad enough that it
gets blown away by systemd.
-- Steve
next prev parent reply other threads:[~2020-04-24 13:28 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-24 2:42 [PATCH] printk: Add loglevel for "do not print to consoles" Tetsuo Handa
2020-04-24 13:28 ` Steven Rostedt [this message]
2020-04-24 14:00 ` Tetsuo Handa
2020-04-24 14:31 ` Steven Rostedt
2020-04-24 15:28 ` Tetsuo Handa
2020-04-24 15:42 ` Steven Rostedt
2020-04-24 15:52 ` Dmitry Safonov
2020-04-24 16:10 ` Tetsuo Handa
2020-04-24 16:21 ` Steven Rostedt
2020-04-24 16:34 ` Tetsuo Handa
2020-04-25 0:46 ` Sergey Senozhatsky
2020-04-25 1:07 ` Tetsuo Handa
2020-04-27 6:21 ` Sergey Senozhatsky
2020-04-28 11:33 ` Tetsuo Handa
2020-04-28 12:18 ` Michal Hocko
2020-04-28 13:11 ` Tetsuo Handa
2020-04-28 15:45 ` Michal Hocko
2020-04-28 16:23 ` Tetsuo Handa
2020-04-29 14:21 ` Michal Hocko
2020-04-29 16:35 ` Tetsuo Handa
2020-05-13 6:26 ` Sergey Senozhatsky
2020-05-13 7:58 ` Tetsuo Handa
2020-05-13 10:04 ` Petr Mladek
2020-05-13 10:49 ` Michal Hocko
2020-05-13 11:24 ` Tetsuo Handa
2020-05-13 12:19 ` Petr Mladek
2020-05-13 12:59 ` Tetsuo Handa
2020-05-14 8:00 ` Petr Mladek
2020-05-14 11:23 ` Tetsuo Handa
2020-05-14 16:26 ` Petr Mladek
2020-05-14 23:24 ` Tetsuo Handa
2020-05-13 11:03 ` Tetsuo Handa
2020-05-13 12:34 ` Petr Mladek
2020-05-13 13:46 ` Steven Rostedt
2020-05-13 14:03 ` Tetsuo Handa
2020-05-13 13:55 ` Steven Rostedt
2020-05-13 15:20 ` Tetsuo Handa
2020-05-06 9:45 ` Tetsuo Handa
2020-05-06 15:26 ` Joe Perches
2020-05-07 0:50 ` Tetsuo Handa
2020-05-07 1:02 ` Joe Perches
2020-05-07 5:13 ` Tetsuo Handa
2020-05-07 5:30 ` Joe Perches
2020-05-07 5:39 ` 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=20200424092816.62a61b1d@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=dima@arista.com \
--cc=laoar.shao@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhocko@suse.com \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=pmladek@suse.com \
--cc=sergey.senozhatsky@gmail.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).