On Fri, 2022-05-20 at 13:57 +0100, Chris Down wrote:
> [Once the goals of this patch are generally agreed upon, it can be
> split
> out further with more detailed changelogs if desired.]
> 
> Consoles can have vastly different latencies and throughputs. For
> example, writing a message to the serial console can take on the
> order
> of tens of milliseconds to get the UART to successfully write a
> message.
> While this might be fine for a single, one-off message, this can
> cause
> significant application-level stalls in situations where the kernel
> writes large amounts of information to the console.
> 
It's more than just application-level stalls. I have seen
some cases of the kernel spending so much time logging things
to serial console that it thinks it locked up, and panics as
a result of how slow the serial console is.

Adding insult to injury, because the log level is sytem wide,
we only see _some_ of the hints of why the kernel started
spewing like that in the netcons logs.

If we print all the information, we will have more hosts panic
because we spent too much time in the serial console code.

If we print less information, we won't find out some of the
other things causing issues on systems.

Having per console log levels will allow us to avoid the
serial console issues, and gather all the info we need on
other stuff happening on the system.

-- 
All Rights Reversed.