Re: [RFC PATCH v2] printk: console: Allow each console to have its own loglevel
From: Chris Down
Date: Wed Jul 13 2022 - 10:32:39 EST
Petr Mladek writes:
The problem is clear. But the big part of the problem is that printk()
tries to show the messages on all consoles immediately.
I wonder how much the per-console loglevel would be needed
when the console handling is offloaded to per-console kthreads, see
https://lore.kernel.org/all/20220421212250.565456-1-john.ogness@xxxxxxxxxxxxx/
It causes that printk() should "never" block and each console might
run on its own speed.
It still might be useful from some reasons:
+ Serial consoles might miss messages because the old messages are
over-written before they reach the console. It might be solved
by big enough buffer.
+ printk() still tries to show the messages immediately in some
critical situations, for example, early boot, watchdog warnings,
suspend, reboot, OOps, panic(). The slow consoles might still
cause stalls and put the system into its knees.
+ People might need to explicitly disable the kthreads, for
example, when debugging a situation when kthreads are not
scheduled.
Indeed. In addition to these, there are cases (like the pstore case mentioned
by Vincent) where we want to bump the console loglevel up to the maximum for
debugging, but it still doesn't make sense to emit it over all consoles --
especially netconsoles where processing capacity on the netconsole
receiver/server is likely limited. The same is true for things like baseboard
management controllers where they may blindly store the console output in a
similar fashion.
The kthread offloading is definitely going to help a lot here here, but to
capably be able to use netconsole in prod we're going to need both.
PS: I am sorry for the late response. I am still snowed under
many tasks. The printk kthreads are complicated and need
a lot of attention. Plus there was a sickness, vacations,
and other tasks.
Don't worry, I totally understand :-) I really appreciate you getting back.