On (02/12/19 15:29), John Ogness wrote: > > 1. The printk buffer is protected by a global raw spinlock for readers > and writers. This restricts the contexts that are allowed to > access the buffer. [..] > 2. Because of #1, NMI and recursive contexts are handled by deferring > logging/printing to a spinlock-safe context. This means that > messages will not be visible if (for example) the kernel dies in > NMI context and the irq_work mechanism does not survive. panic() calls printk_safe_flush_on_panic(), which iterates all per-CPU buffers and moves data to the main logbuf; so then we can flush pending logbuf message panic() printk_safe_flush_on_panic(); console_flush_on_panic(); We don't really use irq_work mechanism for that. > 3. Because of #1, when *not* using features such as PREEMPT_RT, large > latencies exist when printing to slow consoles. Because of #1? I'm not familiar with PREEMPT_RT; but logbuf spinlock should be unlocked while we print messages to slow consoles (call_consoles_drivers() is protected by console_sem, not logbuf lock). So it's spin_lock_irqsave(logbuf); vsprintf(); memcpy(); spin_unlock_irqrestore(logbuf); console_trylock(); for (;;) call_console_drivers(); // console_owner handover console_unlock(); Do you see large latencies because of logbuf spinlock? > 5. Printing to consoles is the responsibility of the printk caller > and that caller may be required to print many messages that other > printk callers inserted. Because of this there can be enormous > variance in the runtime of a printk call. That's complicated. Steven's console_owner handover patch makes printk() more fair. We can have "winner takes it all" scenarios, but significantly less often, IMO. Do you have any data that suggest otherwise? > 7. Loglevel INFO is handled the same as ERR. There seems to be an > endless effort to get printk to show _all_ messages as quickly as > possible in case of a panic (i.e. printing from any context), but > at the same time try not to have printk be too intrusive for the > callers. These are conflicting requirements that lead to a printk > implementation that does a sub-optimal job of satisfying both > sides. Per my experience, fully preemptible "print it sometime maybe" printk() does not work equally well for everyone. -ss
