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

On Thu, 2009-02-26 at 21:45 -0800, Andrew Morton wrote:
On Thu, 26 Feb 2009 21:27:52 -0800 Arjan van de Ven <arjan@xxxxxxxxxxxxx> wrote:


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.

I was actually kinda surprised by the patch - it needs moderate changes
to each driver. I'd have thought that it would be possible to arrange for
_all_ drivers to have their interrupt handlers automagically called from
process context with no driver changes.

Did anyone ever try that? I think they did...

Yes, current preempt-rt does exactly that, as mentioned in the
changelog. That same changelog also mentions why this isn't such a hot
idea:


"The implementation provides an opt-in mechanism to convert drivers to
the threaded interrupt handler model contrary to the preempt-rt patch
where the threaded handlers are enabled by a brute force switch. The
brute force switch is suboptimal as it does not change the interrupt
handler -> tasklet/softirq interaction problems, but was the only way
which was possible for the limited man power of the preempt-rt
developers."


So the idea is that we want people to re-think and change their
interrupt routines to take advantage of the benefits of threaded
interrupts and avoid the endless context switching between threaded
interrupts handler, softirq/tasklet/workqueue contexts, which preempt-rt
now has.

The only way to avoid that is by pushing all softirq/tasklet/worklet
code into the threaded handler, and the only way to do that is by
reworking the drivers.

Since there are too many drivers to count on our few hands, we need an
opt-in, so that we can gradually migrate towards this scheme.



--
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

  • Re: [patch 3/4] genirq: add a quick check handler
    ... The handler could just as now handle/not handle the interrupt, ... sometimes from irq and sometimes from thread context. ... fast interrupts that it may want to handle directly from hardirq context ... Most of the IRQ handler, whether run in a thread or IRQ context, will be ...
    (Linux-Kernel)
  • Re: revert yenta free_irq on suspend
    ... On Mon, 1 Aug 2005, Dave Airlie wrote: ... > handler on a shared IRQ and another device on the chain interrupts it ... You can't fix all drivers, ... where the second stage was done with interrupts disabled and atomically. ...
    (Linux-Kernel)
  • Re: 2.6.27-rc6 xen soft lockup
    ... device interrupts are bound to vcpu 0 and there's nothing much else to ... During the time of the lockup the cpu load, as measured with cacti, was about 4% ... So I would say mostly idle ... # Device Drivers ...
    (Linux-Kernel)
  • Re: [RFC][PATCH 2/2] PM: Rework handling of interrupts during suspend-resume
    ... not generate an irq. ... Subject: PM: Rework handling of interrupts during suspend-resume ... Introduce two helper functions allowing us to prevent device drivers ... suspend and resume. ...
    (Linux-Kernel)
  • Re: User vs. Worker threads
    ... There are some drivers that Microsoft releases that use METHOD_NEITHER. ... user-mode context and runs only in kernel mode. ... is shut down or the thread terminates itself by calling ... It has all the worker threads. ...
    (microsoft.public.win32.programmer.kernel)