Re: [patch 4/4] genirq: add support for threaded interrupt handlers

[Andrew Morton <akpm@linux-foundation.org>]

On Fri, 27 Feb 2009 09:05:10 +0100 Peter Zijlstra <peterz@infradead.org> wrote:

> > What is the plan (if any) for integrating threaded interrupt handlers
> > with softirqs?  I guess things will "just work" at present, and
> > threaded softirqs happen in a later patch?
> 
> Thing is, stuff that now needs softirq could be directly done in the
> threaded handler, ergo softirq usage should decline (and hopefully
> disappear all together - famous last words).
> 
> We only use softirq/workqueues/tasklets because we need a preemptible
> environment, which the traditional irq handler didn't provide. With
> threaded interrupts we do have that.

ah.  I was specifically thinking of net/core/dev.c.  That's our
heaviest user of interrupts and softirqs, I expect?

> > I'd have thought that the softirq latency could get quite a bit worse
> > with this proposed threaded-irq patch?
> 
> Due to the propagation of wakeups? irq wakes up thread, thread wakes up
> softirq, etc?
> 
> Yes it would, another good reason to simply use the threaded handler to
> do whatever the softirq used to do, no?
> 
> > I suppose we could just run the softirq handlers directly after running
> > the irq handler, from the IRQ thread.  Rather than having to poke
> > softirqd all the time?
> 
> One could I suppose, except that softirqs are per-cpu and threaded
> interrupts are not, so they don't map that well. We played around with
> this on preempt-rt for a while, but it kept on breaking stuff.
> 
> Its all a lot more tracktable when you get to change the driver, as you
> have more information.
> 
> > Thwap me if this was all in whatever-changelog-that-was as well ;)
> 
> Hehe, no you got some good points this time around ;-)
> 
> > Also...
> > 
> > Given that this threaded-irq code appears to be new and not very tested
> > in -rt, I think it would be a good idea to convert some popular drivers
> > (e1000/e1000e) so that the core code gets a good thrashing before we
> > merge it.
> 
> Right, Thomas did the EHCI usb driver, the network driver you propose is
> a tad hard since it relies on the whole network stack softirq stuff.
> Re-working the whole net-stack to make use of threaded handlers is a
> massive undertaking

oh.  That rather changes the perspective on the whole exercise.  hrm.

> -- although I seem to remember someone doing it a
> few years back and seeing a general performance improvement, Thomas
> still got a link to that work?
> 
> But yes, it would be prudent to convert a few frequently used driver to
> this model before merging I suppose.