Messages in this thread | | | Date | Thu, 26 Feb 2009 21:27:52 -0800 | From | Arjan van de Ven <> | Subject | Re: [patch 4/4] genirq: add support for threaded interrupt handlers |
| |
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
| |