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

On Thu, 26 Feb 2009 15:32:16 -0800
Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:

On Thu, 26 Feb 2009 13:28:23 -0000
Thomas Gleixner <tglx@xxxxxxxxxxxxx> 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
--
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/

Relevant Pages