Explain the purpose of interrupt handling in devices

Imagine you’re deep in focused work, and instead of your phone constantly buzzing to check if you have new messages, it just interrupts you instantly the moment something actually arrives. That’s a far better system than checking your phone every thirty seconds “just in case.” This exact idea — being interrupted only when something actually needs attention, rather than constantly checking — is the entire philosophy behind interrupt handling in computer systems, and it’s one of the most important efficiency mechanisms in operating system and hardware design.

What Is an Interrupt?

An interrupt is a signal sent to the CPU by hardware or software indicating that an event has occurred which needs immediate attention. When the CPU receives an interrupt, it temporarily suspends whatever it’s currently executing, saves its current state, and jumps to a special piece of code called an Interrupt Service Routine (ISR) or interrupt handler, which deals with the event. Once handled, the CPU restores its previous state and resumes exactly where it left off.

Interrupts come in two broad categories:

• Hardware interrupts — generated by physical devices: a keyboard key press, a mouse movement, a network packet arriving, a disk finishing a read operation, a timer tick.
• Software interrupts (traps/exceptions) — generated by the CPU itself or by software, such as a system call, a division-by-zero error, or a page fault.

Why Interrupt Handling Exists: The Alternative Is Polling

To understand why interrupts matter, it helps to understand the alternative: polling. In a polling system, the CPU would repeatedly check (“poll”) each device in a loop to see if it needs attention — “Is the disk done? No. Is the keyboard pressed? No. Is the disk done? No…” — over and over, thousands of times per second.

This is enormously wasteful. The CPU burns cycles checking devices that are almost always idle, cycles that could otherwise run useful application code. Given the vast speed mismatch between CPU cycles (sub-nanosecond) and typical human/device input rates (milliseconds or slower), a purely polling-based system would waste the overwhelming majority of CPU time just asking “are you done yet?”

Interrupts flip this model: instead of the CPU constantly asking devices if they need attention, devices tell the CPU when they need attention, and the CPU can spend the rest of its time doing productive work — including, importantly, letting the CPU enter low-power sleep states between interrupts, which is critical for battery-powered devices like laptops and smartphones.

POLLING MODEL:                    INTERRUPT MODEL:
CPU: "Done yet?" -> No            CPU: [doing useful work...]
CPU: "Done yet?" -> No            Device: [finishes] -> sends interrupt signal
CPU: "Done yet?" -> No            CPU: [pauses work, handles event, resumes]
CPU: "Done yet?" -> Yes!
(wasted cycles in between)

How Interrupt Handling Works — Step by Step

1. Event occurs on a device (e.g., a network card receives a packet).
2. The device asserts an interrupt request (IRQ) signal, typically via a dedicated hardware line or, in modern systems, via Message Signaled Interrupts (MSI/MSI-X) sent as a special memory write rather than a physical wire.
3. The interrupt controller (historically the Intel 8259 PIC — Programmable Interrupt Controller — now generally the APIC, Advanced Programmable Interrupt Controller, in modern x86 systems) receives this signal, prioritizes it against other pending interrupts, and forwards it to the CPU.
4. The CPU finishes its current instruction (interrupts are typically only serviced at instruction boundaries), then:
   • Saves the current program counter and processor state (registers, flags) onto the stack or a dedicated save area.
   • Looks up the appropriate handler address in the Interrupt Vector Table (IVT on older x86 real mode systems) or Interrupt Descriptor Table (IDT) on modern x86 protected/long mode systems, indexed by the interrupt number.
   • Jumps to the Interrupt Service Routine (ISR) associated with that interrupt.
5. The ISR executes — typically kept as short and fast as possible, doing minimal essential work (like copying data out of a hardware buffer) and deferring more extensive processing.
6. The CPU restores the saved state and resumes the interrupted program exactly where it left off, as if nothing happened from that program’s perspective.

Interrupt Priorities and Masking

Not all interrupts are equally urgent. A power-failure interrupt is far more critical than “keyboard key pressed.” Systems handle this through:

• Interrupt priority levels — higher-priority interrupts can preempt the handling of lower-priority ones.
• Interrupt masking/disabling — the CPU can temporarily disable (mask) certain interrupts during critical sections of code where being interrupted would cause inconsistent state (e.g., while updating a shared kernel data structure).
• Non-Maskable Interrupts (NMI) — reserved for truly critical events (like hardware failures or watchdog timeouts) that cannot be disabled/ignored even during masked sections.

Top Halves and Bottom Halves (Deferred Work)

A crucial design principle in modern operating systems (especially visible in the Linux kernel) is keeping the actual interrupt handler — the “top half” — extremely short, because interrupts often run with other interrupts disabled or at elevated priority, and long-running handlers would hurt system responsiveness and could even cause missed interrupts from other devices.

To solve this, OS kernels split interrupt handling into two phases:

• Top half (hard IRQ handler): Runs immediately, does the absolute minimum — e.g., acknowledge the interrupt to the hardware, copy incoming data from a hardware FIFO buffer into a kernel buffer, and schedule further work.
• Bottom half (deferred processing): Does the more time-consuming work later, outside the strict interrupt context, using mechanisms like:
  • Tasklets and softirqs (Linux)
  • Deferred Procedure Calls (DPCs) (Windows)
  • Work queues (Linux, for tasks that might sleep, unlike tasklets)

This division ensures the system stays responsive to new interrupts while still getting all necessary processing done.

Interrupts and Context Switching

When an interrupt fires, the CPU performs something conceptually similar to (but technically distinct from) a context switch — it must save enough state to resume the interrupted process later. This is different from a full process context switch performed by the scheduler, but it shares the fundamental requirement: nothing about the interrupted program’s state should be lost or corrupted by the intervening interrupt handling.

This is also deeply connected to system calls, which are often implemented as software interrupts/traps (historically int 0x80 on x86 Linux, now typically the faster syscall/sysenter instructions) — when a user program requests a kernel service, it effectively triggers a controlled, deliberate “interrupt” into kernel mode.

Real-World Examples Across Operating Systems

Linux: You can inspect real interrupt activity directly:

cat /proc/interrupts

This shows, per CPU core, how many times each interrupt line has fired — invaluable for diagnosing which device is generating excessive interrupts (a common cause of high CPU usage on systems with a struggling network card or misbehaving driver).

Windows: Interrupt handling is managed through the HAL (Hardware Abstraction Layer) and kernel’s interrupt dispatching code, with DPCs used extensively for bottom-half-style deferred processing. Windows Performance Monitor can track “Interrupts/sec” as a system health metric.

Android/iOS: Both, being built on Linux and Darwin/XNU kernels respectively, use the same fundamental interrupt architectures underneath, with mobile-specific tuning heavily focused on minimizing unnecessary wake-ups from interrupts to preserve battery life — this is part of why modern mobile OSes aggressively batch and coalesce timer-based interrupts.

Practical Example: A Minimal Conceptual ISR (Pseudocode)

// Simplified conceptual example - not real kernel code
void keyboard_interrupt_handler(void) {
    disable_interrupts();          // avoid re-entrant issues
    scancode = read_keyboard_port(); // grab data immediately (top half)
    enqueue_to_input_buffer(scancode);
    send_eoi_to_interrupt_controller(); // acknowledge the interrupt
    enable_interrupts();
    schedule_bottom_half(process_keyboard_input); // defer heavier work
}

Troubleshooting Interrupt-Related Issues

• High CPU usage with no obvious process cause: Check /proc/interrupts (Linux) or the “Interrupts and DPCs” percentage in Windows Task Manager/Resource Monitor — a malfunctioning driver or device generating excessive interrupts (“interrupt storm”) is a classic culprit.
• Audio crackling/stuttering: Often caused by interrupt latency issues, frequently from poorly written or conflicting drivers delaying timely servicing of audio hardware interrupts.
• System freezes on specific hardware actions: Can indicate an interrupt handler bug, sometimes from a faulty or outdated driver holding interrupts disabled too long.
• IRQ conflicts (mostly historical, but still possible in embedded/legacy systems): Two devices sharing an IRQ line inappropriately can cause missed or misattributed interrupts; modern PCIe with MSI/MSI-X largely eliminates this by giving each device its own dedicated interrupt vector.

Best Practices for Driver/Systems Developers

1. Keep top-half ISR code as short and fast as possible; defer real work to bottom halves.
2. Avoid blocking or sleeping operations inside a hard interrupt context.
3. Always acknowledge interrupts properly to the interrupt controller to avoid missing subsequent events.
4. Use modern mechanisms like MSI-X on PCIe devices where possible, for better scalability across multiple CPU cores compared to legacy shared IRQ lines.
5. For latency-sensitive systems (audio, real-time control systems), carefully audit interrupt handling paths for worst-case latency, not just average-case performance.

Summary

Interrupt handling exists to let the CPU respond to hardware and software events efficiently, without wasting cycles constantly polling idle devices. It works through a coordinated dance between devices, interrupt controllers (APIC), and the CPU’s interrupt descriptor table, with modern kernels splitting handling into fast top halves and deferred bottom halves for responsiveness. From keyboards and network cards to power-management events and system calls themselves, interrupts are the fundamental mechanism that lets modern operating systems feel responsive while still running dozens of processes and managing dozens of devices simultaneously.

FAQs

Q: What’s the difference between an interrupt and a system call? A system call is a deliberate software-triggered interrupt/trap initiated by a user program to request a kernel service; a hardware interrupt is triggered externally by a device, independent of what the currently running program is doing.

Q: Can interrupts be disabled? Yes, most interrupts can be masked/disabled temporarily by the OS during critical sections, except Non-Maskable Interrupts (NMIs), reserved for truly critical events.

Q: Why do modern systems prefer MSI/MSI-X over traditional IRQ lines? Because MSI/MSI-X delivers interrupts as memory writes rather than shared physical wires, allowing many more independent interrupt vectors and better distribution across multiple CPU cores, improving scalability.

Q: What happens if an interrupt occurs while another interrupt is being handled? Depending on priority level and masking state, it may be queued, immediately preempt the current handler (if higher priority), or be temporarily blocked until the current handler completes or explicitly re-enables interrupts.

References

• Intel 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A — Interrupt and Exception Handling.
• Linux Kernel Documentation — Interrupt handling: https://www.kernel.org/doc/html/latest/core-api/genericirq.html
• Microsoft Learn — Interrupt Handling and DPCs: https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/introduction-to-interrupt-objects
• Silberschatz, Galvin, Gagne — Operating System Concepts, Chapter on I/O Systems.