On Thu, 15 Nov 2012, Alan Stern wrote:
> 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?
The way I've seen people using it is:
threaded_handler()
again:
handle_stuff();
case A:
/* Wait for timer or new interrupt */
if (hrtimer_sleep(...))
goto again;
handle_timeout();
break;
case B:
....
return;
> 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).
Correct.
> > 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.)
Well, the reason why the API says that is because you are doing lots
of work in interrupt context and you probably not only disable
interrupts for that, you also hold the proper locks to protect against
the eventually incoming interrupt on the other cpu.
So sure, this needs some thought whether it's worth the trouble, but
last I looked a few years ago (when I just had a stab on it), it
definitely looked worthwhile to simplify a lot of things by simply
serializing them naturaly. Don't misunderstand me. You still will need
locks :)
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
