Re: [patch 4/4] genirq: add support for threaded interrupt handlers

[Arjan van de Ven <arjan@infradead.org>]

On Thu, 26 Feb 2009 15:32:16 -0800
Andrew Morton <akpm@linux-foundation.org> wrote:

> On Thu, 26 Feb 2009 13:28:23 -0000
> Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> > Add suppport for threaded interrupt handlers. This is a more strict
> > separation of the primary interrupt handler, which runs in hard
> > interrupt context, and the real interrupt handler, which handles the
> > real device functionality, than the existing hardirq/softirq
> > separation.
> > 
> > The primary hard interrupt context handler solely checks whether the
> > interrupt originates from the device or not. In case the interrupt
> > is asserted by the device the handler disables the interrupt on the
> > device level. This must be the only functionality of the primary
> > handler and this restriction has to be carefully monitored to avoid
> > unresolvable locking scenarios with a fully preemptible kernel.
> > 
> > The threaded handler allows to integrate hardware related
> > functionality and softirq/tasklet functions in the handler
> > thread.
> > 
> 
> A typical device driver will do:
> 
> some_function(...)
> {
> 	spin_lock_irqsave(&dev->lock);
> }
> 
> irq_handler(...)
> {
> 	spin_lock(&dev->lock);
> }
> 
> and this does not deadlock, because the driver "knows" that the IRQ is
> disabled during the execution of the IRQ handler.
> 
> But how is this optimisation supported with IRQ threads?  Do we leave
> the IRQ disabled during the thread execution?  Or does the driver need
> to be changed?
> 
> Bearing in mind that the driver might choose to split the IRQ handling
> between hard-irq context fastpath and process-context slowpath (I
> hope), and that each path might want to take the same lock.
> 


Realistically, for the "we go threaded interrupts" case (which is
opt-in), I think the only sane option is
* the quickhandler runs with irqs off
* the "slow" threaded handler runs with irqs on
And we guarantee both of these conditions from the core, to the point
that I think we should not allow any other combination.

This also should be fine for basically all cases; the quick handler
really needs to be quick so irq off makes sense, and the slow handler
can, worst case, turn off interrupts by itself, but normally is
preemptable etc etc.


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org