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