A key question that's usually asked is, why should I use threaded interrupts at all when the regular hardirq-type interrupt exists? The complete answer is a bit elaborate; the following are the primary reasons why:
- To really make it real time.
- It eliminates/reduces softirq bottlenecks. Since the threaded handler actually runs its code in process context, it's not considered to be as critical a code path as a hardirq handler; hence, you can take a little longer with interrupt handling.
-
- While a hardirq executes IRQn, that IRQ line is disabled on all the cores across the system. If it takes a while to execute to completion (of course, you should design it so that it doesn't), then the system's response can significantly drop; on the other hand, while a threaded handler executes, the hardware IRQ line is enabled by default. This is good for performance and responsiveness. (Note that there will be many cases where...
