On (01/19/18 16:42), Dave Young wrote: [..] > > [I'm not entirely sure I see why do we have printk_delay() in > > vprintk_emit()... I mean I probably can see some reasoning behind > > it, but at the same it makes sense to slow down console_unlock() > > as well] > > Looks like I am the guy who added the code :) LOL :) > Actually no special reason, just did not thinking about the performance > issue at all at that time.. it's quite reasonable to have it in vprintk_emit(), actually. the thing is that it limits the rate at which new messages appear in the kernel log buffer, which does not necessarily correspond to the rate at which new messages appear on the consoles. printk has a "direct path" printk -> console_unlock() -> consoles, and "indirect path" - when it fails to acquire console semaphore, because it's locked by someone else. that someone else, a console_sem owner, might be scheduled out under console_sem; all printks in the meantime will just log_store() messages [after printk_delay()]. once the console_sem owner will be back to running it will resume console_unlock() printing loop and print out all pending messages immediately [modulo preemption]. so there are ways for messages to bypass printk_delay() and appear on the consoles with no visible delay. additionally printk_delay() does touch_nmi_watchdog() so we, technically, are fine with moving it to console_unlock(). -ss _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
