lkml.org 
[lkml]   [2013]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/4] printk: Defer printing to irq work when we printed too much
Hi!

> > > > > Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
> > > > > Signed-off-by: Jan Kara <jack@suse.cz>
> > > >
> > > > When a message takes tens of seconds to be printed, it usually means
> > > > we are in trouble somehow :)
> > > > I wonder what printk source can trigger such a high volume.
> > > Machines with tens of processors and thousands of scsi devices. When
> > > device discovery happens on boot, all processors are busily reporting new
> > > scsi devices and one poor looser is bound to do the printing for ever and
> > > ever until the machine dies...
> >
> > Dunno. In these cases, would it make sense to:
> >
> > 1) reduce amount of text printed
> I thought about this as well. But
> a) It doesn't seem practical as you would have to modify lots of drivers
> and keep them rather silent. That seems rather fragile. Plus you will
> not display some potentially useful information.
> b) It doesn't address the real underlying problem that the way printk() is
> currently implemented, there is no bound on the time CPU spends in the
> loop printing from buffer to console. And the fact that this loop
> sometimes happens with interrupts disabled makes the situation even
> worse.
>
> > 2) just print [XXX characters lost] on overruns?
> We don't overrun the printk buffer so no characters are lost. It just
> takes too long to feed the whole printk buffer through serial console...

Yes, I know. No characters are lost, but we spend seconds with
interrupts disabled, breaking the system. (SCSI timeouts? We do
keyboard autorepeat in software these days...)

Would it be better to just drop the characters?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


\
 
 \ /
  Last update: 2013-11-16 13:01    [W:0.038 / U:0.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site