Messages in this thread | | | Date | Fri, 27 Feb 2009 00:15:32 -0800 | From | Andrew Morton <> | Subject | Re: [patch 4/4] genirq: add support for threaded interrupt handlers |
| |
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.
| |