Understanding Linux SoftIRQs: Why, When, and How They Work

Soft interrupt analysis: due to a busy schedule, this post summarizes Linux kernel soft interrupts (softIRQs) and will later cover tasklets and workqueues.

1. Why SoftIRQs

When writing drivers, an interrupt handler runs with interrupts disabled, so the system cannot respond to other external interrupts, potentially causing missed interrupts. Linux splits interrupt work into two parts: a portion handled in the interrupt context (with interrupts disabled) and a portion deferred to software interrupts, where interrupts are re-enabled, allowing the system to handle other external interrupts.

2. When SoftIRQs Are Triggered

SoftIRQs are triggered after a hardware interrupt handler finishes. The function irq_exit invokes softirq processing.

Invocation of invoke_softirq requires two conditions: it must not be called from within a hardware interrupt or another softirq, and there must be pending softirqs.

In the Linux process data structure, the macro

#define preempt_count() (current_thread_info()->preempt_count)

uses preempt_count to indicate whether the CPU is in an interrupt or softirq context.

The bits 8–23 of preempt_count record nesting counts for hardware and softirq handling, preventing re‑entry of softirqs on the same CPU. On ARM CPUs, interrupts are disabled during hardware interrupt handling, so softirqs are only invoked after hardware interrupts are re‑enabled.

3. SoftIRQ Processing Flow

The function __do_softirq balances three concerns: avoiding lost interrupts, limiting interrupt handling time, and respecting interrupt priority.

The processing steps are:

Call local_softirq_pending to obtain pending softirq bits.

Call __local_bh_disable to disable softirqs on the current CPU, preventing re‑entry.

Clear pending bits with set_softirq_pending(0).

Enable hardware interrupts.

Iterate over each pending bit; if set, invoke the corresponding softirq handler while hardware interrupts remain enabled.

After the loop, disable hardware interrupts again, check for new pending softirqs, and if the loop has not exceeded ten iterations, repeat; otherwise, wake up the ksoftirqd kernel thread.

4. Handling SoftIRQ Kernel Thread

If softirqs remain pending after ten iterations, the kernel wakes the per‑CPU ksoftirqd process, which runs in process context rather than interrupt context. This thread processes pending softirqs in an outer loop (sleeping when none are pending) and an inner loop that checks CPU usage and yields if it runs too long, ensuring fair CPU sharing.