Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On (01/11/18 20:30), Steven Rostedt wrote:
[..]
> Today, printk() can print for a time of A * B, where, as you state
> above:
> 
>    A is the amount of data to print in the worst case
>    B the time call_console_drivers() needs to print a single
> 	  char to all registered and enabled consoles
> 
> In the worse case, the current approach is A is infinite. That is,
> printk() never stops, as long as there is a printk happening on another
> CPU before B can finish. A will keep growing. The call to printk() will
> never return. The more CPUs you have, the more likely this will occur.
> All it takes is a few CPUs doing periodic printks. If there is a slow
> console, where the periodic printk on other CPUs occur quicker than the
> first can finish, the first one will be stuck forever. Doesn't take
> much to have this happen.

console_sem owner can stuck in console_unlock() not because of printk-s
happening right now on other CPUs, but because those printk-s could have
happened while console_sem owner was preempted. when it comes back it has
a ton of pending messages.

I said it before - "we stuck in console_unlock() because others CPUs
printk right now a lot" is not always true. we have preemption. and
the "last console_sem owner prints it all" is not good in this case.

> With my patch, A is fixed to the size of the buffer. A single printk()
> can never print more than that. If another CPU comes in and does a
> printk, then it will take over the task of printing, and release the
> first printk.

yes. and "another CPU" that comes to take over has to print all the
pending messages. from whatever context it's currently in. and bringing
A * B below C can be quite tricky, if possible at all (!). most likely
people will just add more touch_nmi_watchdog().

again, I don't disagree on "let's bound printk". yes, we totally
should! but the bound must be realistic if we want to fix the damn
thing (either with printk_kthread, or hand off, or anything else).

	-ss

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]
  Powered by Linux