Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Andi Kleen]

On Thu, Oct 02, 2008 at 02:31:46PM -0700, Greg KH wrote:
> On Thu, Oct 02, 2008 at 04:46:09PM +0200, Andi Kleen wrote:
> > Thomas Gleixner <tglx@xxxxxxxxxxxxx> writes:
> > >
> > >  - move long running handlers out of the hard interrupt context
> > 
> > I'm not sure I'm really looking forward to this brave new world
> > of very long running interrupt handlers. e.g. what do you
> > do for example when some handler blocks for a very long time?
> 
> We have this issue today with some irqs (USB is known for issue here...)
> 
> So I don't think this is a big issue, and in the end, a better idea as
> it might force us to confront some of the big abusers and fix them.

Not sure I follow? You're saying you want to first allow very long running
IRQ handlers and then after the fact somehow fix them?  Sounds like a weird
proposal to be honest.

The problem of course is that if you have such a very slow hardirq (let's
say one that runs for tens of ms) that what happens when another
interrupt comes in? How deep is your hardware queue?  Or will you 
just lose events in that case?

I suspect in the end you'll need another "fast interrupt" anyways
if the hardware queue is not deep enough to buffer at the software
side. Sounds a bit like the existing "interrupts" vs "softirq" 
doesn't it?

So I'm just not sure what the "slow interrupt handler" will give
you longer term. It just sounds like a redundant concept to me.

The other issue is that if you allow sleeping locks in the interrupt
handler what guarantee is that it won't block for even longer than
tens of milliseconds? And lose even more events.

-Andi

-- 
ak@xxxxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/