A question about threaded IRQs

Posted Dec 12, 2008 2:39 UTC (Fri) by mikov (guest, #33179)
Parent article: A new realtime tree

Can somebody explain how threaded interrupt handlers differ from simply using a work queue? I also looked at http://lwn.net/Articles/302043/ but I am no closer to an answer.

In my understanding "threaded interrupt handlers" are simply minimal top halves who wake up a dedicated thread to do teh work of the bottom half (without the usual restrictions). Can't that already be done on a case by case basis in the mainline without a new API?

to post comments

A question about threaded IRQs

Posted Dec 12, 2008 3:05 UTC (Fri) by nevets (subscriber, #11875) [Link] (3 responses)

Yes it can be done today with the current code, but that will put a heck of a lot of code in each driver that wants to do it. It would need to create its own thread and have its top half only disable the device, and wake up that thread. Then this thread would be in a loop waiting to service the interrupt.

Then each driver would probably do this in its own little way. Having an new API for something that would have lots of users and prevent code duplication is a good thing. But that is just for the threaded interrupt per devices.

The RT tree does a big ax approach. All device handlers become threads without the device even knowing that it is happening. In this case, the threads are at the IRQ layer. That is, if you have two devices sharing the same IRQ, they will also share the same thread. This allows the RT tree to preempt any device interrupt handler when it needs to. And with this change, most spin locks can simply be a mutex. That is the reason for the new lock API.

A question about threaded IRQs

Posted Dec 12, 2008 5:46 UTC (Fri) by mikov (guest, #33179) [Link] (2 responses)

Thanks!

I have a further question about shared IRQs in the RT tree. When saying that devices sharing an IRQ also share a thread, do you mean only the top halves, or all of the processing?

If it is the latter, isn't that a serious limitation? After all tasklets from devices sharing an IRQ can run simultaneously on different CPUs.

A question about threaded IRQs

Posted Dec 12, 2008 15:04 UTC (Fri) by nevets (subscriber, #11875) [Link] (1 responses)

Only the top half is shared. The soft irqs and tasklets also run as a thread, but there is a softirq thread for each softirq and per CPU. That is, if you have 8 CPUS, you will see 8 sirq-netrx threads, one per ever CPU.

Each softirq has its own thread. This lets you prioritize the softirqs as well, where you can not do that with vanilla linux. You can raise the network softirqs over the other softirqs.

A question about threaded IRQs

Posted Dec 12, 2008 17:15 UTC (Fri) by mikov (guest, #33179) [Link]

That makes sense. I really appreciate the explanation.

As usual the great articles combined with the incredible level of the other subscribers makes LWN more than worthwhile...