On 2016/03/03 0:59, Jan Kara wrote:
> This patch makes printk() completely asynchronous (similar to what
> printk_deferred() did until now). It appends message to the kernel
> printk buffer and queues work to do the printing to console. This has
> the advantage that printing always happens from a schedulable contex and
> thus we don't lockup any particular CPU or even interrupts. Also it has
> the advantage that printk() is fast and thus kernel booting is not
> slowed down by slow serial console. Disadvantage of this method is that
> in case of crash there is higher chance that important messages won't
> appear in console output (we may need working scheduling to print
> message to console). We somewhat mitigate this risk by switching printk
> to the original method of immediate printing to console if oops is in
> progress. Also for debugging purposes we provide printk.synchronous
> kernel parameter which resorts to the original printk behavior.
A few questions.
(1) How do you handle PM/suspend? I think kernel threads including
workqueue will be frozen during suspend operation. Maybe we can use
an atomic_t counter (like oom_victims) which forces synchronous
printing if counter value > 0.
(2) Can we have a method for waiting for pending data to be flushed
with timeout? If I want to emit as much messages as SysRq-t from
schedulable context, I want to wait for flush before proceeding.
This is different from using atomic_t counter suggested in (1), for
asynchronous printk() helps reducing RCU duration; queuing to string
buffer from RCU context and emitting from !RCU context will be
preferable.
(3) Is reliability of SysRq-t changed by this patch? I mean, does this
patch make SysRq-t prone to drop traces if the logbuf was not large
enough?
(4) This will be outside of this proposal's scope, but it would be nice
if we can selectively allow each console driver to control loglevel
to emit. For example, send all kernel messages to serial console
(console=ttyS0,115200n8) but send only critical messages to login
console (console=tty0). I'm interested in logging via serial console
and netconsole but not via login console. Since traces sent to login
console is swept away soon, waiting for login console is wasteful.
(5) This will be outside of this proposal's scope, but it would be nice
if printk() can combine multiple logs and pass to console drivers.
For example, logging via netconsole will become significantly faster
if printk() can combine multiple logs up to ethernet packet's size.
A single stack trace can likely be sent using one ethernet packet.
