Understanding Linux Interrupt Handling: Tasklets, SoftIRQs, and Workqueues

Most Simple Interrupt Mechanism

The simplest interrupt method follows the chip manual: an entry in the interrupt vector table jumps to a specific handler function, where the required work is performed. This direct approach is common in microcontroller courses and offers clear, straightforward behavior.

Bottom Half Processing

The first action of an interrupt handler is to mask the interrupt (or effectively do nothing, since clearing the IF flag also masks it), ensuring that the same interrupt type cannot re‑enter while it is being handled. As systems grew more complex, handlers began to do more work, leading to missed interrupts. To avoid this, Linux separates interrupt receipt (still masked) from the actual processing, which runs later in the "bottom half" when interrupts are enabled.

In the diagram, int0 triggers func0, which quickly queues a request and returns, allowing int0 to be re‑enabled. The queued request is later processed by funcA, which can run longer without blocking further interrupts.

SoftIRQ

Linux centralises the non‑preemptible part of interrupt handling in do_IRQ. New handlers are registered with request_irq. The bottom‑half work is placed in do_softirq, known as a softirq, and handlers are added via open_softirq.

Tasklet

When the number of interrupts grew beyond what softirqs could efficiently handle, the tasklet mechanism was introduced. Tasklets use an untyped queue that runs only when an interrupt occurs, eliminating the need for costly polling loops. Their advantages are:

No limit on the number of tasklet types.

High efficiency without table‑lookup loops.

Support for SMP (symmetric multiprocessing).

Workqueue

Workqueues are implemented as kernel threads that act as interrupt‑guard threads. They allow long‑running tasks to be offloaded from the interrupt context, avoiding delays for other interrupts. Because they run in thread context, all thread‑compatible APIs can be used.

Tasklets may also execute in thread context, depending on scheduling.

Usage Summary

When registering an interrupt with request_irq, keep the handler as simple as possible—only actions that must occur while the interrupt is masked should be performed. All other work belongs in the bottom half.

Softirqs are rarely used directly; they mainly serve as the implementation basis for tasklets.

Workqueues should be avoided unless a task truly requires thread context. Most interrupt‑related work can be handled by the driver itself, making workqueues unnecessary.

In most cases, after the simple handler, the appropriate bottom‑half mechanism—preferably a tasklet—should be employed to complete the remaining processing.