Re: + printk-do-cond_resched-between-lines-while-outputting-to-consoles.patch added to -mm tree

[Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>]

On (12/03/15 10:57), Jan Kara wrote:
[..]
> > > CPU2 still can cause lots of troubles. consider
> > > 
> > > CPU0		CPU1			CPU2
> > > printk		
> > > ...		printk_deferred		
> > > printk					wake_up_klogd
> > > 						wake_up_klogd_work_func
> > > 							console_trylock
> > > 								console_unlock
> > > 
> > > printk_deferred() may be issued by scheduler, for example.
> > 
> > IOW, may be we can start limiting the number of bytes printed in console_unlock()
> > from irq contexts. Which is quite ugly, yes. We basically don't know how much time
> > we spend in call_console_drivers(); some of the consoles can do 'internal' spin_lock
> > loops in ->write() handlers, etc. So something like this (below) probably will not
> > really help, but still it's not always OK to do `while (1)' loop in console_unlock()
> > for irqs.
> 
> What we really want is pushing the printing into async context (unless
> forced by debug option or oops in progress). Because what you do here fixes
> only a small fraction of the problem space. I have patches which fix more
> of it (https://lkml.org/lkml/2015/10/26/16) but they are still not enough
> because on large machines e.g. udev times out because printing messages
> about inserted hardware over serial console just takes too long.

absolutely agree. thanks for the link!

	-ss