Busy-waiting with interrupts disabled

Busy-waiting with interrupts disabled

[Alan Stern]

How long is it okay to busy-wait with interrupts disabled?  Are there 
any clear-cut guidelines?

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
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?

Alan Stern

Re: Busy-waiting with interrupts disabled

[Steven Rostedt]

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?
> 
> 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.

-- Steve

Re: Busy-waiting with interrupts disabled

[Steve Calfee]

On 12/12/11 14:12, Alan Stern wrote:
> How long is it okay to busy-wait with interrupts disabled?  Are there 
> any clear-cut guidelines?
> 
> 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
> excessive.  Fortunately it never takes that long unless the hardware is
> broken.)
> 

This is a very subjective issue, as to how much is too much. Keep in
mind that when we had 1 MIP computers a delay of 1 to 2 ms would "waste"
from 1000 to 2000 potential instructions. With 3 gighz processors, the
potential waste jumps to 3,000,000 to 6,000,000 instructions. I know
that clock speed does not equal mips and that most processors spend most
of their time waiting for memory, but still, the waste increases with
processor speed.

Regards, Steve

Re: Busy-waiting with interrupts disabled

[Thomas Gleixner]

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