On (04/06/17 19:33), Pavel Machek wrote:
> This patch set gives up part of the printk() reliability for
> latency (at least unless we detect we are really in trouble) which is IMHO
> a good trade-off for lots of users (and others can just turn this feature
If they can ever realize they were bitten by this feature.
Can we go for different tradeoff?
In console_unlock(), if you detect too much work, print "Too many
messages to print, %d bytes delayed" and wake up kernel thread.
"too many messages" is undefined. console_unlock() can be called from
IRQ handler or with preemtion disabled, or under spin_lock, or under
RCU read lock, etc. etc. By the time we decide to wake up printk_kthread
from console_unlock() it may be already too late.
besides, this does not really address any of the concerns you have
pointed out in other emails. we might be unable to wake_up printk_kthread
(because there is a misbehaving higher prio process, or because the
scheduler is misbehaving, etc. etc.) so the "emergency mode" is still
here and still requires special handling.