I - O management — polling, interrupt-driven, DMA: Visual walkthrough

Step 1 — Two clocks, wildly out of step

WHAT. Draw the whole problem as two timelines: one for the CPU, one for the device. A timeline is just a horizontal line where left is earlier and right is later. A short tick on the line = "one small unit of time passes."

WHY start here. Every cost formula on this page is really "how much of the CPU's timeline gets wasted while the device's timeline crawls along." If you can see the two timelines side by side, the formulas will draw themselves. This is the whole trick.

PICTURE. In the figure, the CPU ticks are packed tightly (fast); the device produces one "ready" pulse far to the right (slow). Look at the amber gap — that gap is the enemy.

Figure — I - O management — polling, interrupt-driven, DMA

Step 2 — Polling: fill the whole gap with useless checks

WHAT. Make the CPU do the simplest possible thing: sit in a loop reading the device's status register (the little box that says busy/ready — see Memory-mapped I/O vs Port-mapped I/O for how the CPU even reaches that box). Each loop pass costs $t_{p o l l}$ . We keep looping until the amber gap ends.

WHY. We want to count the waste. Counting how many $t_{p o l l}$ -boxes fit inside the $T_{d e v}$ gap is just a division — the most natural question a picture of "small boxes filling a big gap" can ask.

PICTURE. The gap $T_{d e v}$ is tiled edge-to-edge with grey poll-boxes. Every box except the last one found the device not ready → coloured wasted.

Edge case — a fast device. If $T_{d e v}$ is tiny (device almost always ready), the gap holds maybe one box. Then polling wastes almost nothing and has zero setup cost — this is the one case where polling wins. The picture makes it obvious: a short gap can't hold many boxes.

Step 3 — The overlap idea: stop staring, go do work

WHAT. Instead of tiling the gap with checks, let the CPU leave and do other useful work during $T_{d e v}$ . When the device finishes, it fires an interrupt (an electrical "tap on the shoulder" — see Interrupts and ISR) that yanks the CPU back for a moment.

WHY this tool and not polling. Polling's flaw was filling the gap. The interrupt lets us overlap the gap with real work, so the gap costs the CPU nothing except the one moment it's pulled back. We're trading a big waste for a small fixed fee.

PICTURE. The device's timeline still has the same long gap, but the CPU timeline is now full of useful work (cyan), pierced by a single amber spike where the interrupt lands.

Step 4 — When does the shoulder-tap beat the staring?

WHAT. Compare the two costs for one data unit: polling burns the whole gap $T_{d e v}$ ; interrupts burn one spike $t_{in t}$ .

WHY a comparison. "Which is better" is always a question about which bar is shorter. So we draw two bars.

PICTURE. Two horizontal bars: a long grey polling bar of length $T_{d e v}$ , a short amber interrupt bar of length $t_{in t}$ . The winner is whichever is shorter.

For a slow device ( $T_{d e v}$ huge) the long bar dwarfs the fee → interrupts win. This is the normal case (disks, keyboards).

Step 5 — The trap: a fast device flips the picture

WHAT. Now shrink $T_{d e v}$ hard: a fast network card is ready again almost instantly, firing one interrupt per byte at millions of bytes per second.

WHY show this. The contract says cover every case, including the degenerate one where our new tool backfires. If we don't, the reader gets ambushed later.

PICTURE. The CPU timeline is now a forest of amber interrupt spikes packed so tightly there's barely any cyan work-time left between them. The fee $t_{in t}$ , paid $N$ times, has eaten the whole line.

Step 6 — DMA: delegate the whole block, get one tap at the end

WHAT. Add a new piece of hardware, the DMA controller, that moves every byte between device and memory by itself over the memory bus. The CPU only (1) programs it with an address and a count $N$ , then (2) gets one interrupt when count hits zero.

WHY this tool. Steps 2–5 all had the CPU personally touch each byte → cost scales with $N$ . To break the scaling we must remove the CPU from the per-byte loop entirely. Delegation is the only move that does that.

PICTURE. The device↔memory arrow now runs through the DMA box, bypassing the CPU. The CPU timeline is almost entirely cyan work, with a single amber spike at the very end labelled "count = 0, done".

Step 7 — The one honest catch: cycle stealing

WHAT. The DMA controller and the CPU share one memory bus. Only one can drive it per cycle. When DMA grabs the bus for a word, the CPU must wait that cycle.

WHY include it. "DMA makes the CPU 100% free" is the tempting lie. The bus is a shared road, and bus arbitration decides who gets it.

PICTURE. One bus road; DMA and CPU take turns. A few CPU ticks are greyed-out ("stalled") exactly where a DMA word slipped in.

The one-picture summary

WHAT. All three CPU timelines stacked, for the same $N$ -byte job: polling (fully wasted), interrupt (a forest of spikes), DMA (nearly all useful work + one end spike). This single frame is the derivation.

Formula The result we built from zero

Method	CPU cost for $N$ bytes	scaling
Polling	$N$ moves $+ \frac{T _{d e v}}{t _{p o l l}}$ wasted polls	$O (N)$ + waste
Interrupt	$N \cdot t_{in t}$	$O (N)$
DMA	$t_{se t u p} + t_{in t}$	$O (1)$

Recall Feynman: the whole walkthrough in plain words

Two clocks tick — a fast CPU and a slow device — and the gap between them is where all the trouble lives. Polling fills that gap with pointless "ready yet?" checks: count how many checks fit in the gap and that's your waste. Interrupts say: don't stand there, go work, I'll tap your shoulder when I'm done — brilliant when the gap is long, but if the device is fast it taps you a million times and the taps drown you. DMA hires a helper that moves the entire block itself and taps you exactly once at the end — so no matter how many bytes, your cost is basically flat. The only fine print: the helper and you share one hallway (the bus), so now and then it makes you pause a beat while it walks through. That's the whole story — polling $O (N)$ -with-waste, interrupts $O (N)$ , DMA $O (1)$ .

Recall Quick self-check

Which method's CPU cost does NOT grow with block size $N$ ? ::: DMA — it is $O (1)$ , one setup plus one completion interrupt. Why can interrupts lose to polling? ::: A fast device fires one interrupt per byte; $N \cdot t_{in t}$ overwhelms the CPU. What is the amber gap in Step 1? ::: $T_{d e v}$ , the time the slow device takes to become ready.

Related deep vault reading: Device Drivers, Disk Scheduling, CPU utilization and throughput.