From: Petr Mladek <pmladek@suse.com>
To: Chris Down <chris@chrisdown.name>
Cc: linux-kernel@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Steven Rostedt <rostedt@goodmis.org>,
John Ogness <john.ogness@linutronix.de>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Tony Lindgren <tony.lindgren@linux.intel.com>,
kernel-team@fb.com
Subject: Re: [PATCH v7 11/13] printk: docs: Add comprehensive guidance for per-console loglevels
Date: Fri, 21 Nov 2025 16:52:48 +0100 [thread overview]
Message-ID: <aSCK0Kl5DXX1eYNS@pathway.suse.cz> (raw)
In-Reply-To: <60de5c9e249579d8d4e5a9423067157a462eb763.1763492585.git.chris@chrisdown.name>
On Wed 2025-11-19 03:08:01, Chris Down wrote:
> The per-console loglevel feature documentation could use some practical
> guidance. This commit adds:
>
> - Examples section covering runtime configuration, effective loglevel
> checking, and boot-time configuration
> - Common use case demonstrating high-performance netconsole with quiet
> serial console fallback
> - Performance impact section explaining how per-console loglevels reduce
> latency by filtering messages before slow console writes
> - Troubleshooting section addressing common issues like messages not
> appearing, loglevel constraints, and minimum console loglevel
I would remove the section about the "minimum console loglevel",
see below.
> - Edge cases section documenting behavior with concurrent writes,
> console unregistration, and global loglevel changes
>
> The guidance interleaves advice about many parts of this patchset, so
> let's have it in a distinct commit.
>
> This documentation will help users understand how to effectively use and
> debug per-console loglevels.
>
> +Performance Impact
> +------------------
> +
> +When a console has a higher (less verbose) loglevel than the global level,
> +messages that would normally be sent to that console are filtered out before
> +the console write callback is invoked. This eliminates the latency that would
> +be incurred by writing those messages to slow consoles (e.g., serial ports).
The above section is either confusing or wrong ;-) A higher loglevel
number means that more loglevel are allowed and the console is more verbose.
> +For example, setting a serial console to WARN level (4) while keeping
> +netconsole at INFO level (6) prevents INFO and NOTICE messages from being
> +written to the slow serial port, reducing application stalls during verbose
> +logging periods.
> +
> +Serial console writes can take tens of milliseconds per message. During
> +periods of heavy logging (e.g., during network debugging or block I/O tracing),
> +this can cause significant application-level stalls. By setting a higher
> +per-console loglevel for the serial console, you can avoid these stalls while
> +still capturing all messages on faster consoles like netconsole.
This is true for legacy consoles. The drivers converted to nbcon
API offload messages to a kthread when the system is working properly.
It prevents the stalls but the console might be far behind and
the oldest messages can get lost when the log buffer is full.
And the stalls are still possible when the system enters an
emergency, e.g. Oops, still, or WARN().
I think how to update this section. I would write something like:
Performance Impact
------------------
Kernel messages used to be flushed to the consoles immediately even
from a context where the scheduling is not possible. It increases
a chance to see the messages even when the system is in a bad state.
But it might cause significant application-level stalls (e.g., during
network debugging or block I/O tracing). Note that serial console
writes can take tens of milliseconds per message.
The console drivers are being converted to nbcon API (the letter 'N'
in /proc/consoles output). These drivers write the messages in a
dedicated kthreads when the system is working properly. It reduces
the risk of stalls. But the messages are still flushed immediately
when the system detects an emergency situation, for example Oops,
stall, or a warning. Also the messages can get lost when the ring
buffer is full and the console driver is far behind with flushing.
For example, setting a serial console to WARN level (4) while keeping
netconsole at INFO level (6) prevents INFO and NOTICE messages from being
written to the slow serial port. It reduces the risk of application
stalls or message loses during verbose logging periods.
> +Setting below minimum_console_loglevel fails
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +If you get an error when trying to set a loglevel, check the system-wide
> +minimum::
> +
> + cat /proc/sys/kernel/console_loglevel
> +
> +Per-console loglevels cannot be set below this minimum. This is a safety
> +feature to ensure critical messages are always visible.
This section is not valid anymore. I think that it is from an earlier
version of the patchset where the per-console loglevel only allowed
to reduce the verbosity. But this version allows to simply replace
the global setting to any valid value.
Or the section was about the "minimum_console_loglevel" variable.
But it is basically hardcoded to 1. I doubt that anyone
modifies it in practice.
I would just remove this section..
Best Regards,
Petr
next prev parent reply other threads:[~2025-11-21 15:52 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-18 19:06 [PATCH v7 00/13] printk: console: Per-console loglevels Chris Down
2025-11-18 19:06 ` [PATCH v7 01/13] printk: Avoid delaying messages that aren't solicited by any console Chris Down
2025-11-18 19:33 ` Chris Down
2025-11-19 15:46 ` Petr Mladek
2025-11-18 19:06 ` [PATCH v7 02/13] printk: Use effective loglevel for suppression and extended console state Chris Down
2025-11-18 19:07 ` [PATCH v7 03/13] printk: console: Implement core per-console loglevel infrastructure Chris Down
2025-11-18 19:34 ` Chris Down
2025-11-19 16:49 ` Petr Mladek
2025-11-18 19:07 ` [PATCH v7 04/13] printk: Ignore per-console loglevel in sysrq Chris Down
2025-11-19 16:51 ` Petr Mladek
2025-11-18 19:07 ` [PATCH v7 05/13] printk: Add synchronisation for concurrent console state changes Chris Down
2025-11-19 16:58 ` Petr Mladek
2025-11-18 19:07 ` [PATCH v7 06/13] printk: Support toggling per-console loglevel via syslog() and cmdline Chris Down
2025-11-20 10:05 ` Petr Mladek
2025-11-18 19:07 ` [PATCH v7 07/13] printk: console: Introduce sysfs interface for per-console loglevels Chris Down
2025-11-20 16:50 ` Petr Mladek
2025-11-21 11:38 ` Petr Mladek
2025-11-18 19:07 ` [PATCH v7 08/13] printk: Constrain hardware-addressed console checks to name position Chris Down
2025-11-18 19:07 ` [PATCH v7 09/13] printk: Support setting initial console loglevel via console= on cmdline Chris Down
2025-11-21 14:05 ` Petr Mladek
2025-11-18 19:07 ` [PATCH v7 10/13] printk: Add sysctl interface to set global loglevels Chris Down
2025-11-21 14:23 ` Petr Mladek
2025-11-18 19:08 ` [PATCH v7 11/13] printk: docs: Add comprehensive guidance for per-console loglevels Chris Down
2025-11-21 15:52 ` Petr Mladek [this message]
2025-11-23 21:21 ` John Ogness
2025-11-18 19:08 ` [PATCH v7 12/13] printk: Deprecate the kernel.printk sysctl interface Chris Down
2025-11-18 19:08 ` [PATCH v7 13/13] printk: Purge default_console_loglevel Chris Down
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=aSCK0Kl5DXX1eYNS@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=chris@chrisdown.name \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=john.ogness@linutronix.de \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--cc=tony.lindgren@linux.intel.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
all inboxes | Powered by JetHome®