Re: [PATCH 2/2] printk: Make the console flush configurable in hotplug path

[Petr Mladek <pmladek@suse.com>]

On Sun 2020-09-27 19:05:34, psodagud@codeaurora.org wrote:
> Yes. I agree with you that there are other conditions, which could delay the
> hotplug operation. But this console
> flushing is not needed in the hotplug path.  In the hotplug path, a core is
> trying printing messages
> from other core(by design of printk), delays the whole hotplug operation and
> timers migration.  As timers
> migration gets delayed, it would impact the systems stability in device
> stability testing.
> To avoid timers delay in the timer migration in  debug builds has to choose
> this option.

Again, just from the printk() point of view. The current printk()
design is that it tries to flush the messages to the console
immediately. It increases the chance to see them. The price is
that printk() might delay the code a lot.

Console handled in a dedicated kthread might make printk() fast. But
there might be another problem. Messages might get lost when they
generated faster than they might be shown on slow consoles.

In both cases, you need to think twice whether you really want to
print the messages at all or if you really want to show them on
slow consoles, see console_loglevel.

Also keep in mind that testing is not real life. I believe that
kernel messages are not shown on slow consoles on production devices.

That said, it seems that printk() is not the real problem here. As
others suggest, CPU hotplug is not the right solution for the usecase.

Best Regards,
Petr