lkml.org 
[lkml]   [2009]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.


\
 
 \ /
  Last update: 2009-02-27 09:19    [W:0.157 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site