All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: Pavel Machek <pavel@ucw.cz>
Cc: Tim Bird <tim.bird@am.sony.com>, Matt Mackall <mpm@selenic.com>,
	linux kernel <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@redhat.com>, Jon Smirl <jonsmirl@yahoo.com>
Subject: Re: IRQ off latency of printk is very high
Date: Thu, 1 Nov 2007 11:27:14 -0400	[thread overview]
Message-ID: <20071101152714.GA2489@Krystal> (raw)
In-Reply-To: <20071029185445.GA7742@ucw.cz>

* Pavel Machek (pavel@ucw.cz) wrote:
> Hi!
> 
> > > Hmm, I see this at the beginning of the post-BK era (2.6.12-rc2):
> > > 
> > > 	        spin_lock_irqsave(&logbuf_lock, flags);
> > > 		...
> > > 		spin_unlock(&logbuf_lock);
> > > 		call_console_drivers(_con_start, _log_end);
> > > 		local_irq_restore(flags);
> > > 
> > 
> > Well, I need to do some more research.  This must be in
> > release_console_sem().  I was looking at vprintk, through
> > the ages.  At 2.6.16, it looked like this:
> > 
> >         spin_lock_irqsave(&logbuf_lock, flags);
> >         ...
> >               spin_unlock_irqrestore(&logbuf_lock, flags);
> >               console_may_schedule = 0;
> >               release_console_sem();
> > 
> > but the irq restore has been moving around to different places
> > in that function over the last few years.  I suspect that in the
> > common case the irqsave in vprintk is the one that disables
> > ints.
> > 
> > It appears that formerly interrupts were enabled in vprintk but
> > re-disabled immediately upon entering release_console_sem().
> > As it is now, they're held during formatting, buffering,
> > and output, which seems excessive.
> > 
> > It seems draconian to drain the entire buffer with ints disabled.
> > Is it possible to break this up and send out smaller chunks
> > at a time?  Maybe by putting a chunk loop in release_console_sem()?
> 
> Well, I believe someone got
> 
> DDetetccctted ed 113223 HHzz CPUCPU
> 
> in his dmesg, and now we have this 'draconian' locking. How can we
> prevent mangled messages without it?
> 							Pavel


The main interest seems to be to protect from mixed printk output
between different CPUs in process context. I don't think it would be
that bad if interrupts come and output error messages in the middle of a
printk, isn't it ?

therefore, could we do something like :


if (!in_irq())
  spin_lock(&logbuf_lock);
...
if (!in_irq())
  spin_unlock(&logbuf_lock);

? (yes, this is a crazy idea)

Mathieu


> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

  reply	other threads:[~2007-11-01 15:27 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-25 19:44 IRQ off latency of printk is very high Tim Bird
2007-10-25 20:19 ` Matt Mackall
2007-10-25 21:15   ` Tim Bird
2007-10-25 22:28 ` Mathieu Desnoyers
2007-10-25 22:52   ` Tim Bird
2007-10-25 23:12     ` Matt Mackall
2007-10-25 23:41       ` Tim Bird
2007-10-26  1:23         ` Matt Mackall
2007-10-26 12:57           ` Benny Amorsen
2007-10-26 20:28             ` Matt Mackall
2007-10-29 18:54         ` Pavel Machek
2007-11-01 15:27           ` Mathieu Desnoyers [this message]
2007-11-01 21:11             ` Pavel Machek
2007-11-01 22:19               ` Mathieu Desnoyers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071101152714.GA2489@Krystal \
    --to=mathieu.desnoyers@polymtl.ca \
    --cc=jonsmirl@yahoo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=mpm@selenic.com \
    --cc=pavel@ucw.cz \
    --cc=tim.bird@am.sony.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.