Message-ID: <aSCK0Kl5DXX1eYNS@pathway.suse.cz>
Date: Fri, 21 Nov 2025 16:52:48 +0100
From: Petr Mladek <pmladek@...e.com>
To: Chris Down <chris@...isdown.name>
Cc: linux-kernel@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Sergey Senozhatsky <senozhatsky@...omium.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	John Ogness <john.ogness@...utronix.de>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Tony Lindgren <tony.lindgren@...ux.intel.com>, kernel-team@...com
Subject: Re: [PATCH v7 11/13] printk: docs: Add comprehensive guidance for
 per-console loglevels

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

Powered by blists - more mailing lists