Understanding Linux CPU Scheduling and Interrupt Handling

Linux treats scheduling as the core of the operating system, aiming to maximize CPU utilization while isolating workloads and reducing per‑operation costs. The article is divided into three parts, focusing on the scheduler, CPU context, and interrupt mechanisms.

CPU Execution Flow

The CPU executes instructions through a sequence of components:

An automatic counter increments with the clock frequency, serving as the program counter (PC).

A decoder follows the counter and accesses memory built from numerous D‑flip‑flops.

The counter’s value selects a memory address, from which the CPU fetches an instruction.

The fetched instruction is written into an instruction register under CPU‑clock control.

A second decoder parses the instruction into opcode and operands.

The opcode drives the ALU, performing arithmetic or logic operations, with results written back to registers or memory.

Optimizations such as pipelining, branch prediction, superscalar execution, hyper‑threading, SIMD, multi‑level caches, and NUMA are mentioned, but the focus remains on Linux's scheduling.

CPU Context and Switching

Linux is a multitasking OS that runs many more tasks than there are CPUs. It creates the illusion of simultaneous execution by rapidly time‑slicing CPU time among tasks. Before a task runs, the kernel sets up its CPU context—registers and the program counter—so the task can resume correctly.

Contexts are stored in kernel stacks. Each process has its own kernel stack, and each CPU has separate interrupt stacks (hard‑irq and soft‑irq). When a task is rescheduled, its saved context is restored, preserving execution state.

Interrupt Types and Handling

Interrupts originate from hardware devices and are delivered to the CPU via an interrupt controller. The CPU identifies the source and passes control to the kernel.

Hard (hardware) interrupts : Immediate, high‑priority events handled in the hard‑irq context.

Soft interrupts (softirq) : Bottom‑half mechanisms that defer non‑time‑critical work.

Tasklets : Serialized soft‑irq‑like handlers that run on a single CPU.

Work queues : Kernel threads that execute deferred work in process context, allowing sleeping and blocking.

Interrupts are classified as synchronous (exceptions generated by the CPU) or asynchronous (external hardware signals). Synchronous interrupts include faults, traps, and aborts; asynchronous interrupts include maskable and non‑maskable interrupts (NMIs).

Interrupt Affinity

On SMP systems, interrupt affinity binds specific IRQ sources to particular CPUs via /proc/irq/IRQ#/smp_affinity. Proper affinity improves throughput for network, storage, and other high‑interrupt workloads.

Bottom‑Half Mechanisms

The kernel splits interrupt handling into an upper half (quick, time‑critical) and a lower half (deferred). Upper halves run with interrupts disabled; lower halves run as softirqs, tasklets, or work‑queue threads, allowing longer processing without blocking the system.

Softirqs are scheduled by irq_exit(), I/O APIC events, local_bh_enable(), inter‑CPU calls, or when the ksoftirqd thread wakes. They can be forced to run in a kernel thread if execution exceeds thresholds (e.g., >2 ms).

Key Macros for Context Detection

#define in_irq()        (hardirq_count())   // in hard‑irq context
#define in_softirq()    (softirq_count())   // in soft‑irq context
#define in_interrupt()  (irq_count())       // in any interrupt context
#define in_atomic()     ((preempt_count() & ~PREEMPT_ACTIVE) != 0) // any non‑preemptible context

Summary and Best Practices

Interrupt contexts are not schedulable entities; tasks (processes/threads) are.

Priority order: hard‑irq > soft‑irq > process context.

Upper halves must be short; lower halves handle deferred work via softirqs, tasklets, or work queues.

Never sleep in interrupt context; use work queues when sleeping is required.

Proper IRQ affinity and selection of bottom‑half mechanisms improve system throughput and latency.