Re: [Ksummit-discuss] [TECH TOPIC] asynchronous printk

[Christian Borntraeger <borntraeger@de.ibm.com>]

On 07/19/2016 09:46 AM, Christian Borntraeger wrote:
> On 07/19/2016 08:17 AM, Hannes Reinecke wrote:
>> On 07/19/2016 05:47 AM, Sergey Senozhatsky wrote:
>>> Hello,
>>>
>>> Wondering if anyone will be interested in printk-related topics
>>> (or we can handle it in the mailing list).
>>>
>>> What I have on my list is:
>>>
>>>
>>> - synchronous printk()
>>>
>>> printk() prints messages from kernel printk buffer until the buffer
>>> is empty. When serial console is attached, printing is slow and thus
>>> other CPUs in the system have plenty of time to append new messages to
>>> the buffer while one CPU is printing. Thus the CPU can spend unbounded
>>> amount of time doing printing in console_unlock().  This is especially
>>> serious problem if the printk() calling console_unlock() was called with
>>> interrupts disabled, or from IRQ, or from spin_lock protected section
>>> (if the spinlock is contended), etc. etc. IOW, printk() is quite dangerous
>>> function to call in some cases, it can cause different types of lockups
>>> (soft, hard, spinlock), stalls and so on.
>>>
>>> we have some progress on this side. printk() can offload printing from
>>> sensitive and unsafe contexts to a schedulable printk_kthread context (a
>>> special purpose printing kthread).
>>> but "The whole idea remains worrisome", per Andrew :)
>>>
>> Yes. The main problem stems from the fact that printk has two different
>> and conflicting use-cases:
>> - Really urgent, 'I am about to die' messages. Which obviously need to
>>   be printed out as fast as possible.
>> - Rather largish, information/logging 'what I always wanted to tell you'
>>   type of messages. These messages tend to be very large, but at the end
>>   it doesn't really matter _when_ they'll be printed as they are
>>   time-stamped anyway.
> 
> I think you brought up this topic last year in a lightning talk, correct?
> Didn't Linus say "fix the console then"?

Which does not make the problem go away, though, so yes - a session to
discuss this is probably a good idea - it really depends on how strong
Linus opinion on this topic is ;-)

On s390 we have for LPAR the relatively slow operating system messages console,
which goes out to the service element.
In 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=25b41a7b67ee4f4d12cee8a4b8b5929e36c27e29
we provided a console specific fix^Whack to allow to tune the buffer size
and to allow to drop messages. Better solutions are certainly welcome.

Christian