Threaded interrupt handling question in RT kernel

Threaded interrupt handling question in RT kernel

[Jaccon Bastiaansen]

Hello Thomas, Peter

We have a question about threaded interrupt handling:

By default, when using threaded interrupt handlers, the IRQ is
disabled in hard IRQ context and enabled again after all threaded
interrupt handlers connected to that IRQ have run. In this way, high
priority interrupt handlers can be delayed until the lowest priority
interrupt handler thread has run. Therefore it seems that it's not
useful to have a separate thread for each interrupt handler (what's
the use of being able to set interrupt handler thread priorities when
you still have to wait for the one with the lowest priority).

So we think that we should use the request_threaded_irq() function.
The task of the handler that is executed in hard IRQ context is to
check whether the device that it controls is generating an interrupt
and if it does, deactivate the IRQ output of the device and wakeup the
interrupt handler thread by returning IRQ_WAKE_THREAD. By deactivating
the IRQ output, another device connected to the same IRQ can activate
the IRQ again before the interrupt handler thread of the first device
has run. This guarantees that a high priority threaded interrupt
handler of a device on a shared IRQ can run before a low priority
threaded interrupt handler of a device on the same IRQ has run. So
when using threaded interrupt handlers for devices on a shared IRQ,
make sure that all drivers have used request_threaded_irq().
Otherwise, high priority threaded interrupt handlers can be delayed by
low priority threaded interrupt handlers.

Is all this correct or do we miss something?


Regards,
  Jaccon Bastiaansen

Re: Threaded interrupt handling question in RT kernel

[Thomas Gleixner]

On Tue, 16 Aug 2011, Jaccon Bastiaansen wrote:

> Hello Thomas, Peter
> 
> We have a question about threaded interrupt handling:
> 
> By default, when using threaded interrupt handlers, the IRQ is
> disabled in hard IRQ context and enabled again after all threaded
> interrupt handlers connected to that IRQ have run. In this way, high
> priority interrupt handlers can be delayed until the lowest priority
> interrupt handler thread has run. Therefore it seems that it's not
> useful to have a separate thread for each interrupt handler (what's
> the use of being able to set interrupt handler thread priorities when
> you still have to wait for the one with the lowest priority).

That's correct, but RT just makes use of the general facility which is
designed to have a separate thread for each device.
 
> So we think that we should use the request_threaded_irq() function.

You can do that for a specific driver, but we cannot do that in RT for
every driver in the kernel.

> The task of the handler that is executed in hard IRQ context is to
> check whether the device that it controls is generating an interrupt
> and if it does, deactivate the IRQ output of the device and wakeup the
> interrupt handler thread by returning IRQ_WAKE_THREAD. By deactivating
> the IRQ output, another device connected to the same IRQ can activate
> the IRQ again before the interrupt handler thread of the first device
> has run. This guarantees that a high priority threaded interrupt
> handler of a device on a shared IRQ can run before a low priority
> threaded interrupt handler of a device on the same IRQ has run. So
> when using threaded interrupt handlers for devices on a shared IRQ,
> make sure that all drivers have used request_threaded_irq().
> Otherwise, high priority threaded interrupt handlers can be delayed by
> low priority threaded interrupt handlers.
> 
> Is all this correct or do we miss something?

That's how it's designed to work.

Thanks,

	tglx