Re: Would you help to tell why async printk solution was not taken to upstream kernel ?
From: Sergey Senozhatsky
Date: Mon Mar 05 2018 - 21:44:10 EST
One more thing
On (03/06/18 10:52), Sergey Senozhatsky wrote:
[..]
> > If you know the baud rate, logbuf size * console throughput is actually
> > trivial to calculate.
It's trivial when your setup is trivial. In a less trivial case if you
set watchdog threshold based on "logbuf size * console throughput" then
things are still too bad.
So this is what a typical printk over serial console looks like
printk()
console_unlock()
for (;;) {
local_irq_save()
call_console_drivers()
foo_console_write()
spin_lock_irqsave(&port->lock, flags);
uart_console_write(port, s, count, foo_console_putchar);
spin_unlock_irqrestore(&port->lock, flags);
local_irq_restore()
}
Notice that call_console_drivers->foo_console_write spins on
port->lock every time it wants to print out a logbuf line.
Why does it do this?
In short, because of printf(). Yes, printk() may depend on printf().
printf()
n_tty_write()
uart_write()
uart_port_lock(state, flags) // spin_lock_irqsave(&uport->lock, flags)
memcpy(circ->buf + circ->head, buf, c);
uart_port_unlock(port, flags) // spin_unlock_irqrestore(&port->lock, flags);
Now, printf() messages stored in uart circ buffer must be printed
to the console. And this is where console's IRQ handler jumps in.
A typical IRQ handler does something like this
static irqreturn_t foo_console_irq_handler(...)
{
spin_lock(&port->lock);
rx_chars(port, status);
tx_chars(port, status);
spin_unlock(&port->lock);
}
Where tx_chars() usually does something like this
while (...) {
write_char(port, xmit->buf[xmit->tail]);
xmit->tail = (xmit->tail + 1) & (UART_XMIT_SIZE - 1);
if (uart_circ_empty(xmit))
break;
}
Some drivers flush all pending chars, some drivers limit the number
of TX chars to some number, e.g. 512.
But in any case, printk() -> call_console_drivers() -> foo_console_write()
must spin on port->lock as long as foo_console_irq_handler() has chars to
TX / RX.
Thus, if you have O(logbuf) of kernel messages, and O(circ->buf) of user
space messages, then printk() will spend O(logbuf) + O(circ->buf) + O(RX).
So the watchdog threshold value based purely on O(logbuf) (printing to
_all_ of the consoles) will not always work.
-ss