Why Interrupt-Driven I/O Improves CPU Efficiency—and How the Transfer Proceeds
Interrupt-driven I/O improves CPU efficiency because the CPU is not forced to continuously poll device status in tight loops. Instead, the CPU proceeds with other ready work (or enters an idle/low-power state) and only temporarily stops to service the device when the device signals that it is ready—via an interrupt from the device controller to the CPU.
Conceptually, polling wastes cycles because the CPU repeatedly checks a status bit even though the device is often “not ready.” Interrupt-driven I/O converts this wasted waiting into event-based progress: the CPU responds to the actual completion/ready event signaled by hardware. In many systems, the device controller can also use mechanisms like DMA so the CPU involvement is reduced to setup and final completion handling.
Below is the standard “sequence of operations” in an interrupt-driven transfer (and where DMA fits).
Interrupts and Interrupt-Driven I/O (intro lecture)
Key terms to track during the process
- interrupt
- interrupt service routine (ISR)
- device controller
- DMA
- context switch
Sequence of operations in an interrupt-driven I/O transfer
- 1Step 1
A process (or kernel subsystem) issues a read/write system call. The kernel prepares an I/O request and identifies the target device and memory buffer.
- 2Step 2
The OS writes the relevant parameters to controller registers (e.g., buffer address/length, command type such as read/write, and any mode bits).
- 3Step 3
The controller begins the device-side operation. The initiating thread typically becomes blocked waiting for completion, rather than repeatedly checking a status flag.
- 4Step 4
While the device/controller is working, the CPU can execute other ready instructions (or idle). If DMA is used, data moves between device and memory without per-byte CPU involvement.
- 5Step 5
When the controller observes a completion or “data ready” condition, it signals the CPU with an interrupt.
- 6Step 6
Hardware switches control to the appropriate handler: the CPU saves enough execution context (e.g., program counter/state) to resume later, then jumps to the ISR.
- 7Step 7
The ISR first acknowledges/clears the interrupt at the controller to prevent retriggering and reads controller status to determine what completed.
- 8Step 8
If no DMA is used, the ISR may copy data from controller registers into the target memory buffer. With DMA, the ISR usually just verifies completion and updates bookkeeping (e.g., bytes transferred).
- 9Step 9
The ISR updates request state (success/error), places the completed transfer into the appropriate queue, and wakes the blocked process/thread.
- 10Step 10
The CPU restores the saved context and continues executing whatever was running before the interrupt (subject to scheduling policy and the now-woken process possibly being chosen next).
Why this is more CPU-efficient than polling
Polling requires the CPU to repeatedly perform “check status” operations during the device’s waiting time. That can be thought of as converting long device latencies into a large number of CPU instruction cycles doing unproductive work. Interrupt-driven I/O instead:
- Uses hardware to signal only when an event happens (device ready/completed).
- Allows the CPU to run other tasks during the device latency (or idle efficiently).
- Often pairs well with DMA, which further reduces CPU involvement during the bulk data movement phase.
The tradeoff is that interrupts introduce overhead: saving/restoring context and running the ISR. However, for typical I/O devices where readiness/completion times are relatively long compared to CPU instruction times, the overhead is usually far smaller than the wasted polling cycles.
Efficiency intuition
Polling ties up the CPU for the entire device-wait period. Interrupt-driven I/O shifts waiting from “CPU cycles spent checking” to “CPU cycles spent doing other work,” with only brief ISR overhead when the device signals completion.
Interrupt overhead and practical limits
Interrupt-driven I/O is not free: frequent interrupts can increase overhead, require careful ISR design (keep it short), and can affect latency/jitter for time-sensitive workloads.
CPU work during device latency: polling vs interrupt-driven (conceptual)
Illustrative comparison of CPU utilization across a device wait interval.
From I/O request to completion in interrupt-driven operation
Request
T0Process issues I/O; kernel prepares request/buffer."
Controller setup
T1OS writes controller registers; starts device operation."
Device latency
T2CPU does other work/idle; controller/device progresses."
Interrupt signal
T3Controller asserts interrupt on readiness/completion."
ISR execution
T4CPU saves context, acknowledges interrupt, copies/records completion."
Resume + wake
T5Waiting process is woken; CPU resumes normal execution."
Common edge cases and implementation details
Knowledge Check
In interrupt-driven I/O, what allows the CPU to be more efficient than polling?
Explore Related Topics
CPU Slowdown Due to DMA Cycle Stealing (16-bit Transfers)
I/O Interfacing
I/O interfacing connects a CPU with peripheral devices by handling addressing, readiness detection, data movement, and timing synchronization through controllers, registers, and protocols.
- Devices are accessed via memory‑mapped I/O or isolated I/O, each with distinct address spaces and instruction sets.
- Transfer methods include programmed I/O (polling), interrupt‑driven I/O, and DMA, balancing CPU involvement, latency, and throughput.
- Handshaking and buffering reconcile speed mismatches, while parallel, serial, and analog interfaces extend functionality to various signal types.
- Design trade‑offs involve choosing the appropriate addressing scheme, transfer method, and synchronization technique for each device class.
The Intradata Transfer Techniques: Serial I/O, Parallel I/O, or Both?