Messages in this thread | | | Date | Wed, 02 Jul 2008 13:24:58 +0200 | From | Andi Kleen <> | Subject | Re: [Ksummit-2008-discuss] Delayed interrupt work, thread pools |
| |
Leon Woestenberg wrote: > Hello, > > (including linux-rt-users in the CC:, irqthreads are on-topic there)
Actually it's probably not interesting for this case.
> > On Wed, Jul 2, 2008 at 1:02 PM, Andi Kleen <andi@firstfloor.org> wrote: >> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes: >> >>>> how much of this would be obsoleted if we had irqthreads ? >>> I'm not sure irqthreads is what I want... >>> >> I also think interrupts threads are a bad idea in many cases because >> their whole "advantage" over classical interrupts is that they can >> block. Now blocking can be usually take a unbounded potentially long >> time. >> >> What do you do when there are more interrupts in that unbounded time? >> > If by irqthreads the -rt implementation is meant, isn't this what happens: > > irq kernel handler masks the source interrupt > irq handler awakes the matching irqthread (they always are present) > irqthread is scheduled, does work and returns > irq kernel unmasks the source interrupt
I described this case. If the interrupt handler blocks for a long time (as Ben asked for) then the interrupts will not be handled for a long time. Probably not what you want.
BTW this was not a criticsm of rt linux (in whose context irqthreads make sense as I explained) , just an explanation why they imho don't make sense (IMHO) in a non hard rt interruptible kernel and especially not to solve Ben's issue.
> >> Create more interrupt threads? At some point you'll have hundreds >> of threads doing nothing when you're unlucky. >> > Each irqthread handles one irq. > So now new irq thread would spawn for any interrupt.
It was a general description of all possible irqthreads.
-Andi
| |