Interrupt-Driven I/O vs. Polling

Building an Operating System Kernel: Concurrency, I/O & Synchronization

Chapter 7 · Interrupt-Driven I/O vs. Polling

Chapter 6 measured one number: a 1.80x speedup, at one latency, with one other process. This chapter turns that single measurement into a real parameter sweep — varying latency, varying the number of competing processes — and finds a genuinely non-obvious result running in the opposite direction from what intuition suggests.

Finding 1: Speedup Scales Directly With Latency

Verified directly — a real, measured curve converging to the theoretical ceiling

Latency	Poll steps	Block steps	Speedup
10	400	391	1.02x
50	400	351	1.14x
100	400	301	1.33x
190	400	211	1.90x
400	400	201	1.99x

Polling always takes exactly 2x the target work in real steps — completely independent of latency. Blocking's own speedup grows directly with latency: negligible for a short wait, approaching the full 2.0x ceiling once latency meets or exceeds the target work itself.

Finding 2: A Genuinely Non-Obvious Result — More Competitors Shrinks the Advantage

Verified directly — the OPPOSITE of the intuitive guess

Other processes	Poll steps	Block steps	Speedup
1	200	101	1.98x
2	300	251	1.20x
4	500	476	1.05x
8	900	888	1.01x

Adding more real competing processes shrinks the speedup, not grows it — 1.98x with one competitor down to 1.01x with eight. With N other processes, a polling waiter only ever occupies 1/(N+1) of the round-robin rotation — its own wasted turns become a smaller fraction of the whole as N grows. Blocking still always wins — but its biggest relative win is precisely the 2-process case Chapter 6 measured.

Finding 3: The Exact, Directly Counted Cost of Waste

Verified directly — 49 real, scheduled turns spent checking a flag that wasn't true yet

At latency=100, the polling waiter performs 49 individually-counted POLL_DISK checks before even one finds the disk actually done — roughly half the latency, since it only gets every other real step. Every one of those 49 checks is a real, scheduled turn spent producing nothing at all.

Finding 4: An Honest Caveat — What This Model Doesn't Capture

Verified directly — blocking never loses, even at latency=1, but that's a property of the model

Even at the shortest possible latency, blocking is never worse than polling here — because both a POLL check and a block-then-wake transition cost the model exactly one real step. A real machine's own context switch has genuine overhead — register save/restore, cache effects, real scheduler bookkeeping — that can exceed a very short wait's own cost, which is exactly why real systems still use brief spin-based polling for the shortest waits. This chapter's own step-based model doesn't capture that overhead difference — an honest limitation, not a claim that polling is never the right real choice.

Where This Connects

This chapter's finding	What it connects to
Speedup converging to a theoretical ceiling	Course 1 Chapter 9's own aging-scheduler measurement — a real, converging curve rather than a single anecdotal number
More competitors shrinking, not growing, the benefit	Technical Support's own System Monitoring course — a reminder that intuitive guesses about performance need real measurement, not just plausible reasoning
The exact wasted-poll count	Chapter 6's own Finding 1 — the same underlying cost, now measured precisely rather than only observed in aggregate
The honest model-limitation caveat	Building a Database Engine's own honest architectural gap (MVCC never connected to durable storage) — naming what a model doesn't capture is as important as what it does

Hands-On Exercises

Exercise 1

Run a single process with no other ready process at all, comparing polling against blocking for the same disk latency. Confirm they take exactly the same number of real steps, and explain why.

📄 View solution

Exercise 2

Rerun Finding 1's own comparison, but have the "worker" process also need its own real disk read (using blocking either way) after some real work. Confirm blocking's own advantage for the waiter still holds in this more realistic scenario.

📄 View solution

Exercise 3

Set the disk latency far beyond the worker's own target work (effectively infinite). Confirm the measured speedup lands right at the theoretical 2.0x ceiling, and explain precisely why it can't go any higher.

📄 View solution

Chapter 7 Quick Reference

Verified Finding 1: speedup scales directly with latency, converging exactly to a 2.0x ceiling
Verified Finding 2 (non-obvious): more competing processes SHRINKS blocking's own relative advantage, not grows it
Verified Finding 3: the exact, directly-counted number of wasted POLL attempts — not an estimate
Verified Finding 4 (honest caveat): this step-based model doesn't capture real context-switch overhead — real systems still poll briefly for very short waits
Golden rule: a single measured number is an anecdote; a parameter sweep is a finding — always check whether a result holds across the range, not just at one point
Next chapter: Virtual File Systems — an abstraction layer over real storage, building on this chapter's own driver abstraction