On Thu, Oct 02, 2008 at 02:31:46PM -0700, Greg KH wrote:
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@linux.intel.com
--
