What is the difference between threaded interrupt handler and tasklet?

Question

I found an interesting topic, threaded interrupt handler, on https://lwn.net/Articles/302043/. It is not a brand new idea and it intended to replace tasklet. But when I studied its functionality, I found there is no difference between threaded interrupt handler and tasklet. Both of them defer the work and finish the hardware-related issue ASAP in the hard irq and defer the time-consuming part. Could anyone shed me some light on it?

Answer 1

The main difference between softirq's/tasklets and threaded irq's is the context in which they run, and what they can do.

• A threaded irq runs in its own separate thread, and it can do anything any "normal" kernel thread can do. It can do things that potentially block, like acquiring locks or allocating memory, it can be preempted by other threads, it can sleep.
• A softirq/tasklet doesn't have its own context, but rather there are situations where the kernel checks whether any outstanding softirq's are waiting and runs them. Typically this is done after hard irq (top half) processing, or just before returning from a syscall (any random syscall by any random process, doesn't necessarily have anything to do with the interrupt in question). Softirq's also run in an atomic context, they are not allowed to do anything that might block.

The downside of the softirq approach is that it can cause potentially unbounded latency, as the softirq processing runs at essentially "infinite" priority. Though there is a mechanism where the kernel detects if it spends too much time processing softirq's, then it stops and instead wakes a "ksoftirqd" thread to handle them, and that thread is then subject to scheduling just like any other thread in the system.

For an example, if you use your computer for some audio applications. You want your audio application to not cause stutter, so you run it at realtime priority level. Now, as it happens on your PC you also run a webserver serving the latest cat pictures to the internet. For some reason the latest picture becomes very popular, and your PC becomes overloaded with requests. And it can happen that the system spends so much time handling network I/O that your audio application misses its deadline and you hear an annoying pop or stutter when it runs out of buffer. If, instead, network I/O were to be handled by a threaded irq, the scheduler could decide that as important serving cat pictures is, that audio application has even higher priority and it gets to run.

The downside of threaded irq is that needing a separate thread for it means more context switch overhead.

A recent article explaining some issues with softirq's: https://lwn.net/Articles/925540/