On Thu, 15 Nov 2012, Thomas Gleixner wrote: > > > Hmmm. Doesn't that mean there would be no benefit from using threaded > > > interrupt handlers? > > > > Not versus the timers. Threaded interrupt handlers are handy, if you > > want to be able to schedule or run complex code w/o hogging the > > (soft)interrupt system for a long time. It also allows you to move stuff > > which you hand off to tasklets, workqueues or other deferred entities > > into your handler which reduced locking complexities and other problems. > > > > But again, that really depends on what your driver/interrupt handler > > has to do and whether avoiding the handoff of work makes sense or not. > > Bah. Hit send too fast. :) > > That said, it might even make sense versus timers, if you have to > delay operations on the device for time X. You can even just sleep in > your interrupt thread and get woken, when either the timer expires or > another interrupt comes in. How does that work? Does the thread simply run in a big loop, spending most of its time in an interruptible sleep, and calling the threaded handler routine whenever it gets woken up? And it gets woken up whenever the primary handler returns IRQ_WAKE_THREAD? That would mean the timer routine could simply wake up the handler thread, and the rest of the work could be done in the thread's context. All the thread would need to do is check, each time it started up, whether the timer had expired. No locking would be necessary (vs the timer, at least). > Though I'm not familiar enough with the USB code to tell whether any > of this helps or not. Its definitely pointless just to enforce the > threaded handler and not make use of its extended abilities. I see. The USB code does do a reasonably large amount of work in interrupt context. It doesn't have to be that way; it could be in process context -- but the design of the USB subsystem requires that much of the work be carried out with interrupts disabled. (The API states that all the driver callbacks occur with disabled interrupts.) So overall, it looks like there's not very much to be gained from using threaded interrupts here. Maybe I'm wrong, but that's my impression. Thanks, Alan Stern -- 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
