linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
To: Michal Hocko <mhocko@kernel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Petr Mladek <pmladek@suse.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-kernel@vger.kernel.org, Dmitry Safonov <dima@arista.com>,
	Yafang Shao <laoar.shao@gmail.com>
Subject: Re: [PATCH] printk: Add loglevel for "do not print to consoles".
Date: Tue, 28 Apr 2020 22:11:19 +0900	[thread overview]
Message-ID: <b4d74234-8009-9ffd-011f-bd5d1a4b85f6@i-love.sakura.ne.jp> (raw)
In-Reply-To: <20200428121828.GP28637@dhcp22.suse.cz>

On 2020/04/28 21:18, Michal Hocko wrote:
> On Tue 28-04-20 20:33:21, Tetsuo Handa wrote:
>> On 2020/04/27 15:21, Sergey Senozhatsky wrote:
>>>> KERN_NO_CONSOLES is for type of messages where "saved for later analysis" is
>>>> important but "printed for immediate notification" is not important.
>>>> In other words, KERN_NO_CONSOLES is NOT for dying messages where "printed for
>>>> immediate notification" is important.
>>>
>>> per-console loglevel is a user configurable parameter.
>>> KERN_NO_CONSOLES is a hard-coded policy.
>>
>> But given that whether to use KERN_NO_CONSOLES is configurable via e.g. sysctl,
>> KERN_NO_CONSOLES will become a user configurable parameter. What's still wrong?
> 
> How do I as a kernel developer know that KERN_NO_CONSOLES should be
> used? In other words, how can I assume what a user will consider
> important on the console?
> 

Existing KERN_$LEVEL allows a user to determine whether he/she wants that message
to be printed on consoles (even if it spams his/her operation doing on consoles), and
at the same time constrains that user whether that message is saved to log files.
KERN_NO_CONSOLES allows a user to control whether he/she wants that message to be
saved to log files (without spamming his/her operation doing on consoles).

Consoles which are limited by "rows" * "columns" size should receive (ideally) up to
a few lines of messages. Printing more lines on such consoles disturbs users using
such consoles. Let alone printing one thousand lines of messages (e.g. dump_tasks())
on such consoles. Printing one thousand lines of messages on read-only consoles (e.g.
netconsole) might be fine, but non-urgent messages can afford waiting for userspace
to do more sophisticated handling (e.g. evaluate and filter).

Even without per-console loglevel feature, we can reduce spam messages for consoles
by using KERN_NO_CONSOLES. For example, send only the summary part of OOM-killer and
allocation failure messages to both consoles and log files (by not using KERN_NO_CONSOLES),
and send the non-summary part to only log files (by using KERN_NO_CONSOLES with 
KERN_$LEVEL used for summary part in order to make sure that userspace daemon will
save both the summary and non-summary parts).

  reply	other threads:[~2020-04-28 13:12 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
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 [this message]
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=b4d74234-8009-9ffd-011f-bd5d1a4b85f6@i-love.sakura.ne.jp \
    --to=penguin-kernel@i-love.sakura.ne.jp \
    --cc=dima@arista.com \
    --cc=laoar.shao@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhocko@kernel.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --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).