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

From: Sergey Senozhatsky
Date: Thu Dec 03 2015 - 19:28:50 EST


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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/