On (03/06/17 21:45), Sergey Senozhatsky wrote:
[..]
> printk kthread changes the behavior of printk in one _corner case_.
> The corner case is quite interesting and actually consists of two corner
> cases. Suppose on SMP system there is only one CPU that printk()-s a lot,
> the rest of CPUs don't lock console_sem and don't printk(). Previously
> that printing CPU had been throttling itself (*) because of console drivers
> call for every printk():
>
> CPU0
>
> printk("a")
> console_unlock()
> call_console_drivers("a")
>
> ...
>
> printk("z")
> console_unlock()
> call_console_drivers("z")
>
> * Given that no other CPU locks the console_sem.
>
> With printk kthread the case turns into this one:
>
> CPU0 CPU1
>
> printk("a")
> wake_up printk_kthread
> ... printk_kthread
> printk("k") console_unlock()
> ... call_console_drivers("a")
> printk("z") call_console_drivers("b")
> call_console_drivers("c")
> ...
>
>
> The second 'corner case' part here is that CPU0 may be much faster
> than printing CPU, which may result in dropped printk messages.
>
> This all is absolutely possible even with out the printk-kthread.
> A single console_lock() call from CPUx will result in exactly the
> same condition. So it's not necessarily a regression. But there may
> be some scenarios in the kernel that may suffer from this change.
> From the top of my head -- sysrq backtrace dump, and, probably, OOM
> print out and backtrace dump.
there is another possibility here.
being always reschedulable potentially can put us at risk of having
unpleasant situations when printk_kthread is getting preempted too
often (well, who knows what can happen on the system), which can slow
down logbuf emit process (printk_kthread) up to the point when printk()
CPUs will force log_store() to begin dropping the messages. this can
happen.
-ss
