An interrupt is a signal that tells the CPU that something needs attention. Instead of forcing the processor to constantly ask every device, “Do you need me yet?”, hardware can raise an interrupt when an event actually happens.
The beginner version is simple: device raises an interrupt → CPU pauses normal work → the kernel runs the correct interrupt handler → the system returns to what it was doing. That basic mechanism is how keyboards, storage devices, network adapters, timers, and many embedded systems get fast attention without wasting CPU time on constant polling.
Why Interrupts Exist
Imagine a computer with no interrupts. The processor might have to repeatedly check the keyboard, mouse, network interface card, storage controller, USB devices, and timers just to see whether anything changed. That approach is called polling.
Polling is sometimes useful, but doing it constantly can waste CPU cycles. Interrupts let hardware announce events only when necessary. A device essentially says, “I have something ready,” and the processor temporarily redirects execution to code that knows how to service that event.
IRQ Means Interrupt Request
IRQ stands for interrupt request. Historically, devices used dedicated interrupt lines routed through the motherboard and interrupt-controller hardware. Modern systems also use message-signaled interrupts, where a device writes a special value that causes the interrupt controller and CPU to recognize the event.
Microsoft’s interrupt-service-routine documentation notes that Windows drivers can handle both traditional line-based interrupts and message-signaled interrupts. The implementation changes, but the purpose is the same: a device needs a controlled path to get processor attention.
An Interrupt Controller Routes the Request
A modern computer can have many interrupt sources, so the processor needs help deciding what happened and which handler should run. Interrupt-controller hardware receives requests, prioritizes them, and routes them toward one or more CPU cores.
On x86 systems, modern interrupt routing is commonly associated with the APIC family of controllers. Other processor architectures have their own designs. The motherboard chipset, CPU architecture, firmware, and operating system all participate in building the final interrupt path.
The ISR Is the First Handler
An interrupt service routine, or ISR, is the code that runs when the operating system accepts a particular interrupt. A physical-device device driver commonly registers the handler that should respond to its hardware.
ISRs are normally designed to do only the time-critical work first. Microsoft recommends quickly capturing volatile device information in the ISR and deferring slower work until later. That keeps the processor from spending too long in a high-priority interrupt context.
Interrupt Handlers Should Be Fast
When the CPU is handling an interrupt, normal work may be delayed. That is why interrupt handlers should usually do the minimum urgent work and then schedule the rest for a lower-priority context.
Windows commonly separates the fast ISR from later work such as a deferred procedure call. Linux has its own mechanisms for splitting urgent interrupt work from deferred processing. The exact names differ, but the performance principle is similar: acknowledge the hardware quickly, preserve critical state, then get out of the highest-priority path.
Hardware Interrupts Come From Devices
A hardware interrupt begins with a physical event outside the currently executing software flow. A packet can arrive at a NIC, a storage controller can finish an I/O operation, a timer can expire, or a USB controller can report a completed transfer.
That makes interrupts fundamental to IT troubleshooting. A driver problem, bad hardware, incorrect firmware, or an interrupt storm can create high CPU use, latency, dropped data, or a device that appears frozen even when the rest of the system is healthy.
Software Can Trigger Exceptions and Traps Too
Not every event that redirects CPU execution comes directly from external hardware. Processors also generate exceptions when software causes conditions such as invalid instructions, divide errors, or page faults. Software can also deliberately enter protected operating-system code through mechanisms used by system calls.
The words interrupt, exception, trap, and fault are sometimes used differently across architectures and operating systems. The important beginner distinction is that hardware interrupts are generally asynchronous external events, while exceptions are usually tied to the instruction stream currently executing.
Page Faults Are a Familiar Exception
The virtual-memory system provides a good example. If a program touches a virtual-memory page that is not currently mapped the way the CPU expects, the processor raises a page fault. The kernel inspects the condition, updates mappings or loads data if appropriate, and then allows the program to continue when the fault is recoverable.
That shows the broader pattern: the CPU detects an event, stops the normal instruction flow, transfers control to privileged code, and resumes later if the operating system can handle the condition safely.
Interrupts Matter in Networking
A busy network adapter can generate a huge number of events. The driver and kernel therefore have to balance responsiveness against overhead. If the operating system interrupted the CPU separately for every tiny packet event at extreme data rates, the interrupt overhead itself could become expensive.
Modern NICs and drivers use techniques such as interrupt moderation, batching, queue steering, and polling hybrids to reduce this cost. That ties interrupts directly to the broader topics of TCP and UDP, packet processing, CPUs, and high-speed networking.
Storage Devices Use Interrupts After I/O Completes
Storage is another classic example. A program requests file data through the operating system. The kernel and file system arrange the I/O. The storage hardware works independently, and then the device can signal completion so the CPU knows the requested operation has progressed or finished.
This event-driven model lets the processor work on other processes and threads instead of waiting in a tight loop for every storage transaction.
Embedded Systems Depend Heavily on Interrupts
Interrupts are also central to real-time firmware. A microcontroller may need to react to a timer edge, sensor transition, serial byte, motor-control event, or emergency input within a predictable amount of time.
Embedded startup code often contains an interrupt-vector table that tells the processor which handler belongs to each interrupt or exception. BitcoinVersus.Tech covered that relationship in the vector-table and startup-code lesson.
This Linux-kernel debugging post gives a real-world example of engineers working on virtual IRQ race conditions—the kind of edge case that appears when interrupt delivery, devices, and kernel timing interact.
Edge-Triggered and Level-Triggered Interrupts
Interrupts can be delivered using different signaling models. An edge-triggered interrupt represents a transition, such as a signal changing state. A level-triggered interrupt remains asserted while a condition is active and generally must be cleared correctly before the system considers the event finished.
The Linux kernel’s generic IRQ documentation describes separate handling paths for edge, level, per-CPU, and other interrupt types. Device drivers can request and manage interrupts without having to implement every low-level interrupt-controller detail themselves.
Interrupt Latency Measures Response Time
Interrupt latency is the delay between an interrupt becoming pending and the processor beginning the relevant handling work. On an ordinary desktop, tiny variations may not matter. In robotics, industrial control, audio, networking, or real-time systems, latency and jitter can become critical engineering limits.
That is one reason high-priority handlers should stay short. Long interrupt-disabled sections or overloaded interrupt paths can delay other time-sensitive work and make the whole system less predictable.
Too Many Interrupts Can Become an Interrupt Storm
An interrupt storm happens when a device or software path generates interrupts so aggressively that the processor spends excessive time servicing them. Possible causes include faulty hardware, driver bugs, incorrectly cleared interrupt status, misconfiguration, or an unusually heavy workload.
On Linux, /proc/interrupts can help show how interrupts are distributed across CPU cores and devices. The kernel community continues to refine that interface for modern high-frequency workloads, which shows that interrupt accounting remains an active systems-engineering concern in 2026.
The Simple Way to Remember Interrupts
An interrupt is a request for immediate CPU attention. An IRQ identifies or carries the request. An ISR is the first handler that responds.
The basic chain is: device or CPU event → IRQ or exception → interrupt controller / processor entry logic → kernel → ISR or handler → deferred work → return to normal execution. Keep that chain in order and the connection between CPUs, drivers, hardware, firmware, and the kernel becomes much easier to understand.
Editor’s Note
Featured image: realistic computer-hardware photograph via Unsplash, cropped to exactly 1200×630. Body circuit-board photograph: Umberto via Unsplash. The Neso Academy and NPTEL videos are distinct and directly relevant to interrupts, IRQs, interrupt controllers, and ISRs. The Bluesky post is directly relevant to Linux virtual-IRQ debugging.
Support and donation options are available through BitcoinVersus.Tech.
BitcoinVersus.Tech is not a financial advisor. Content is provided for informational and educational purposes.
Leave a comment