4.2.37 · D5Operating Systems
Question bank — I - O management — polling, interrupt-driven, DMA
True or false — justify
Polling always wastes CPU cycles, so it is never the right choice.
False — for a device that is almost always ready and very fast, a single poll may succeed immediately, and that beats paying the fixed interrupt-setup + context-save overhead. Polling only wastes cycles when the device is slow relative to the CPU.
Interrupt-driven I/O guarantees the CPU never wastes time waiting.
Mostly true for the waiting, but interrupts introduce their own cost: each interrupt forces a context save/restore. At high data rates that overhead can exceed the polling waste it replaced.
DMA removes the CPU from I/O entirely during a transfer.
False — the CPU is free from copying bytes, but DMA and the CPU share the memory bus. When DMA grabs the bus (cycle stealing) the CPU may stall for that cycle, so it is not entirely contention-free.
More hardware complexity always means better performance.
False — DMA is the most complex yet is overkill for a keyboard sending one byte every 200 ms; the setup cost dwarfs the single-byte payload. "Best" means matching the device's rate and block size, not maximising hardware.
In interrupt-driven I/O the CPU can do useful work while the device is busy.
True — that is the whole point. The device's idle time is overlapped with other CPU work; the CPU only pauses briefly to run the ISR when the device signals ready.
A DMA transfer of 1 byte is faster than an interrupt-driven transfer of 1 byte.
False — for a single byte, DMA still needs programming (address, count, direction) plus one completion interrupt, which is more work than one plain ISR. DMA only wins as the block grows large.
Polling requires no interrupt vector or ISR.
True — polling is pure busy-wait in software; there is no hardware interrupt line, no vector lookup, no ISR. That simplicity is exactly why it needs zero extra hardware.
The status, data, and command registers must live at special I/O ports, not memory addresses.
False — they can be reached either way. See Memory-mapped I/O vs Port-mapped I/O: memory-mapped exposes them as ordinary addresses; port-mapped uses special I/O instructions. The three techniques work with either.
Spot the error
"With DMA, N interrupts fire for an N-byte block, one per byte."
Wrong — DMA raises exactly one interrupt, at completion (count reaches 0). The per-byte interrupt count of N belongs to interrupt-driven I/O, not DMA.
"Polling is O(1) CPU work because it's just one loop."
Wrong — the loop spins, executing iterations while waiting, then does N byte-moves. It is O(N) moves plus a large wasted-poll term, not O(1).
"Interrupts are always better than polling because the CPU never spins."
Wrong — for a high-rate device (millions of bytes/sec) one interrupt per byte means millions of ISR invocations; the accumulated overhead can exceed the polling waste, making interrupts worse. This is the gap DMA fills.
"The ISR reads the status register in a busy-wait loop until the device is ready."
Wrong — the ISR runs because the device is already ready (it raised the interrupt). Busy-waiting on status is the polling technique; putting it inside an ISR defeats the purpose of interrupts.
"DMA needs no interrupt at all — that's why it's efficient."
Wrong — DMA still needs one completion interrupt so the CPU learns the block finished. Its efficiency comes from raising one interrupt instead of N, not from raising zero.
"Cycle stealing means DMA steals CPU registers."
Wrong — it steals memory-bus cycles, not registers. When DMA needs the bus to move a word, it briefly takes the bus and the CPU may stall for that cycle; registers are untouched.
"Since interrupt-driven I/O overlaps work, the total transfer finishes faster than polling."
Not necessarily — the device still takes to become ready either way. Interrupts don't speed the device; they free the CPU to do other work during that same wait. Transfer completion time is bounded by the device, not the CPU technique.
Why questions
Why does polling drive useful CPU utilization during I/O toward zero?
Because the CPU runs the poll loop back-to-back and every iteration before the last finds the device not-ready, so nearly all iterations are pure waste. See CPU utilization and throughput.
Why is one interrupt "per data unit" the failure mode for fast devices?
Each interrupt forces a context save, vector jump, ISR run, and context restore — a fixed cost. Multiply that by millions of units per second and dominates, starving real work.
Why does the CPU still program the DMA controller before every transfer?
The controller is generic hardware; it needs the source/destination address, byte count, and direction for this transfer. Without that setup it wouldn't know what to move or where.
Why must the CPU "save context" before entering an ISR?
The ISR runs on the same CPU and clobbers registers/flags. Saving the interrupted program's state (see Context switching) lets the CPU restore and resume exactly where it left off after the ISR returns.
Why is DMA described as O(1) CPU involvement while interrupt-driven is O(N)?
DMA hands the whole block to autonomous hardware, so CPU work (setup + one completion ISR) is constant regardless of N. Interrupt-driven pays one ISR per unit, so CPU work grows linearly with N.
Why does a device driver choose different techniques for different devices?
The right technique depends on the device's data rate and block size — polling for fast-always-ready, interrupts for slow rare events, DMA for large fast blocks. The driver encodes that decision for its specific hardware.
Why is DMA especially valuable for disk transfers but wasteful for a keyboard?
A disk moves large contiguous blocks (thousands of bytes) where fixed setup cost is amortised across many bytes; a keyboard delivers a single byte per rare keystroke, so DMA's setup exceeds the payload — interrupt-driven fits better. See Disk Scheduling.
Edge cases
If a device becomes ready instantly (before the first poll completes), which method is fastest?
Polling — the first status read already sees "ready," so there is zero wasted spinning and none of the interrupt/DMA setup overhead. This is the classic "device almost always ready" case.
What happens in interrupt-driven I/O if a second interrupt arrives while the ISR is still running?
It is either held pending (masked) or, if higher priority, may pre-empt — handled by the interrupt controller's priority/masking rules. The point is interrupts can nest or queue; the ISR must clear its source before returning to avoid re-triggering. See Interrupts and ISR.
For a 1-byte transfer, rank the three methods by CPU work.
Roughly interrupt-driven ≈ polling (if device is quick) < DMA — for a lone byte DMA's setup + completion interrupt is the most work, inverting the usual large-block ranking.
If (device is as fast as the CPU), does interrupt-driven still beat polling?
No — as shrinks the polling waste , so there's nothing to save, while interrupts still cost . Polling wins in this limit.
What is CPU utilization during a pure busy-wait poll of a slow device?
Effectively 0% useful work — the CPU is "busy" but only spinning on the status register, doing nothing productive while the device is not ready.
During a DMA block transfer with heavy bus contention, can CPU throughput drop even though it isn't copying bytes?
Yes — frequent cycle stealing steals many bus cycles, stalling the CPU's own memory accesses, so effective throughput can dip. It is far better than copying, but not free.
If a device raises an interrupt but the CPU has interrupts disabled (masked), what happens?
The request stays pending until interrupts are re-enabled; then the CPU services it. Masking delays, it does not discard the request — the device holds the line asserted.
Recall One-line summary of the traps
Match the technique to the device's rate and block size: fast-always-ready → polling; slow rare single bytes → interrupts; large fast blocks → DMA. Every trap above is some violation of that matching, or forgetting that DMA still shares the bus and still needs one interrupt.