Messages in this thread | | | Date | Tue, 19 May 2020 16:43:55 +0200 | From | Petr Mladek <> | Subject | Re: [RFC PATCH 3/3] watchdog: Turn console verbosity on when reporting softlockup |
| |
On Thu 2020-03-19 15:48:36, Sergey Senozhatsky wrote: > On (20/03/18 19:05), Eugeniu Rosca wrote: > > My current standpoint is that as long as points [A-D] are met, it > > should do no harm to accept a (partial) fix like seen in my series: > > > > - [A] the patch tackles at least a subset of problematic use-cases > > - [B] the fix is non-intrusive and easy to review > > - [C] there is hope to reuse it in the new lockless buffer based printk > > - [D] there are no regressions employing the major console knobs > > (ignore_loglevel, quiet, loglevel, etc) as it happened in > > a6ae928c25835c ("Revert "printk: make sure to print log on console."") > > So the issue is that when we bump `console_loglevel' or `ignore_loglevel' > we lift restrictions globally. For all CPUs, for all contexts which call > printk(). This may have negative impact.
Another impact is that many more messages might suddenly appear on the console even though admins wanted them quiet because they were slow.
The problem is to define what information is critical. In the ideal world, all messages are visible on the console so that developers could use them for debugging. The console loglevel is there to keep it working in the real world.
IMHO, an acceptable solution would be:
+ Print a single critical message about that a lockup happened + Make it configurable which log level will get used for the details.
Note that there is a pending patchset that allows to show stacks with a given loglevel, see https://lore.kernel.org/linux-riscv/20200418201944.482088-1-dima@arista.com/
Well, I am slightly afraid that it might open a can with hundred of printk-related options shuffling log level for various events.
The upcoming printk kthread might help to handle even more messages on slow consoles. It might allow to increase the default loglevel in these situations. But the problem will still be there. The throughput will always be limited and different people have different opinion on what messages are important.
Best Regards, Petr
| |