mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	USB list <linux-usb@vger.kernel.org>,
	Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: Busy-waiting with interrupts disabled
Date: Tue, 13 Dec 2011 00:42:36 +0100 (CET)	[thread overview]
Message-ID: <alpine.LFD.2.02.1112130040180.3020@ionos> (raw)
In-Reply-To: <1323730061.1377.13.camel@gandalf.stny.rr.com>

On Mon, 12 Dec 2011, Steven Rostedt wrote:

> On Mon, 2011-12-12 at 17:12 -0500, Alan Stern wrote:
> > How long is it okay to busy-wait with interrupts disabled?  Are there 
> > any clear-cut guidelines?

A few usecs nothing more.

> > My feeling is that for ordinary desktop use, 1-2 ms should be about the
> > limit, but other people may feel differently.  (There's one spot in
> > ehci-hcd where the delay can last up to 250 ms, which does seem rather
> 
> "250 ms", holy freaking OUCH! Batman!
> 
> 
> > excessive.  Fortunately it never takes that long unless the hardware is
> > broken.)
> > 
> > No doubt the RT people would say the upper bound should be on the order
> > of a few microseconds or less.  I'd be happy to change ehci-hcd, which
> > has several delays in the 1-2 ms range -- but they tend to be nested
> > inside routines that are called within the scope of spinlock_irq, which
> > means a fair amount of rewriting would be needed.
> > 
> > Any thoughts or recommendations?
> 
> Note that in -rt, spinlocks are really mutexes (unless they are
> raw_spinlocks, which you shouldn't do). Thus, if your spin is with
> spinlock_irq, it wont affect -rt, as it will not have interrupts
> disabled.
> 
> But I could imagine that such a long latency could manifest itself into
> something nasty (lots of interrupts queued up and such) that normal
> desktop users might see a hiccup or two.

Audio folks would be particularly happy about such crap. Aside of that
you can even starve timekeeping that way depending on the wraparound
time of your clocksource and the interrupt/timekeeping affinities at
that point.

Simply don't do that.

Thanks,

	tglx

  reply	other threads:[~2011-12-12 23:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-12 22:12 Alan Stern
2011-12-12 22:47 ` Steven Rostedt
2011-12-12 23:42   ` Thomas Gleixner [this message]
2011-12-12 23:18 ` Steve Calfee

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=alpine.LFD.2.02.1112130040180.3020@ionos \
    --to=tglx@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=stern@rowland.harvard.edu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome