Understanding Linux Interrupt Handling: From Simple Vectors to Tasklets and Workqueues

Basic Interrupt Mechanism

The simplest interrupt handling follows the chip manual: an entry in the interrupt vector table points to a jump instruction that transfers control to a specific handler function. This direct approach is common in microcontroller courses and simple embedded systems because it is straightforward and efficient.

Why a Bottom‑Half Is Needed

When an interrupt occurs, the first action of the handler is to mask that interrupt (or simply clear the IF flag, which effectively masks it) to prevent re‑entry and protect the interrupt context. As systems become more complex, handlers need to perform more work, which can lead to missed interrupts. To avoid this, Linux separates interrupt receipt from processing: the receipt occurs with the interrupt masked, while the actual processing happens later in a “bottom‑half”.

Bottom‑Half Techniques in Linux

Linux provides three mechanisms for bottom‑half processing:

Softirqs : Implemented in the kernel’s do_softirq function. Handlers are registered with open_softirq and invoked from do_IRQ after the top‑half finishes.

Tasklets : Built on top of softirqs but use an untyped queue, removing the 32‑type limit of softirqs. Tasklets run only on the CPU that received the interrupt, supporting SMP without the need for polling.

Workqueues : Represent a pool of kernel threads that execute deferred work outside interrupt context, allowing the use of any thread‑compatible APIs.

Illustration of Bottom‑Half Processing

In a typical scenario, int0 triggers func0, which quickly queues a request to funcA. Because func0 does minimal work, it re‑enables int0 before returning, ensuring that new interrupts can be received even while funcA processes the queued request.

Softirqs in Linux

The kernel places common, non‑preemptible code in do_IRQ. When a driver registers an interrupt with request_irq, the top‑half runs there. The deferred part is placed in do_softirq, which processes registered softirq handlers.

Tasklets: Evolution from Softirqs

As the number of interrupt sources grew, the 32‑type limit of softirqs became a bottleneck. Tasklets were introduced to use an unrestricted queue, eliminating the need for polling all interrupt types. They execute only when an interrupt occurs, offering higher efficiency and SMP support.

No limit on the number of tasklet types.

High efficiency, no table‑lookup loops.

Supports SMP.

Workqueues: Deferring Work to Kernel Threads

Both softirqs and tasklets run in interrupt context, meaning they cannot block or sleep. If a deferred operation takes long, it can delay other interrupts. Workqueues solve this by running the deferred work in dedicated kernel threads, allowing the use of any thread‑compatible functions.

Practical Guidelines for Using Bottom‑Half Mechanisms

Keep request_irq handlers minimal—only perform actions that must run with interrupts disabled.

Move all other processing to the bottom‑half.

Prefer tasklets over softirqs; softirqs are mainly an implementation detail for tasklets.

Use workqueues only when the deferred work requires thread context (e.g., sleeping, blocking I/O).

If interrupt load is high, Linux may offload excess work to the ksoftirqd thread, preventing user‑space starvation.