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

WHY do we need any of this?

A device (say a disk) and the CPU run independently. The CPU must know:

status — is the device busy / ready / has an error?
data — the actual bytes to read or write.
control — commands like "start reading".

These live in device registers (status register, data register, command register), accessed either via special I/O instructions or memory-mapped addresses. The three techniques differ in who watches the status register and who copies the data.

1. Polling (Programmed I/O)

HOW it works (per byte):

while (status_register.busy == 1) ;   // busy-wait loop
data_register = byte;                 // CPU writes the data
command_register = WRITE;             // tell device to act

WHY it feels fine: it is dead simple — no extra hardware, no interrupt setup. For a device that is almost always ready and very fast, polling can even be the fastest option (no interrupt overhead).

WHY it's bad in general: if the device takes 10 ms and the CPU loop spins at nanoseconds, the CPU wastes millions of cycles doing nothing. The CPU is "busy" being useless.

2. Interrupt-driven I/O

HOW it works:

CPU sends command, returns to other tasks.
Device finishes → asserts interrupt line.
CPU finishes current instruction, saves context, jumps to ISR (via the interrupt vector).
ISR moves the byte, clears the interrupt, restores context, returns.

3. DMA (Direct Memory Access)

HOW it works:

CPU programs the DMA controller: source/dest address, count (#bytes), direction.
CPU goes off to do other work.
DMA controller moves bytes device↔memory over the bus, decrementing count.
When count = 0, DMA raises one interrupt: "block done."

Formula CPU work per N-byte transfer

Method	CPU operations for $N$ bytes
Polling	$N$ moves + $\frac{T_{dev}}{t_{poll}}$ wasted polls
Interrupt	$N$ ISR invocations $\approx N\cdot t_{int}$
DMA	$1$ setup + $1$ ISR $\approx t_{int}$ (independent of $N$ )
Derivation of DMA: since the controller handles each byte autonomously, CPU involvement is constant: $O(1)$ instead of $O(N)$ .

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

Putting it together — Forecast then Verify

Flashcards

What problem does all I/O management solve?

Coordinating a fast CPU with slow devices without wasting CPU time.

In polling, what does the CPU repeatedly read?

The device's status register (busy-wait loop).

Main disadvantage of polling?

CPU busy-waits, wasting cycles while the slow device isn't ready.

One situation where polling is actually best?

When the device is almost always ready and very fast, so interrupt overhead would exceed poll cost.

In interrupt-driven I/O, how does the device signal readiness?

It raises an interrupt; the CPU runs an ISR.

Why can interrupt-driven I/O be WORSE than polling for high-rate devices?

One interrupt per byte means huge ISR overhead at high data rates.

What does DMA stand for and do?

Direct Memory Access — hardware moves a whole block device↔memory without CPU copying each byte.

How many interrupts does DMA raise per N-byte block?

Exactly one, at completion.

What is cycle stealing?

DMA borrows the memory bus for a cycle, briefly stalling the CPU.

Per N-byte transfer, CPU involvement: polling vs DMA?

Polling O(N) moves; DMA O(1) (constant, independent of N).

Which three device registers are involved in I/O?

Status, data, and command/control registers.

Order the three methods by increasing CPU offloading.

Polling < Interrupt-driven < DMA.

Recall Feynman: explain to a 12-year-old

Imagine you're cooking and the oven is slow. Polling = you stand at the oven staring at it the whole time — you can't do anything else, total waste. Interrupts = you set a timer bell; you go play, and when it dings you run back, take out one cookie, then go play again — but if the bell dinged every second you'd be running back and forth nonstop. DMA = you hire a helper who watches the oven, takes out all the cookies, and only calls you once when everything's done. You barely lift a finger!

Connections

Interrupts and ISR
Memory-mapped I/O vs Port-mapped I/O
Device Drivers
Memory bus and bus arbitration
Context switching
Disk Scheduling
CPU utilization and throughput

Concept Map

Hinglish (regional understanding)

Intuition Hinglish mein samjho

Dekho, problem simple hai: CPU bahut fast hai aur I/O devices (disk, keyboard, network) bahut slow. To CPU in slow devices ke saath kaise baat kare bina apna time barbaad kiye? Iske teen levels hain. Polling mein CPU baar-baar device ka status register check karta rehta hai — "ready ho? ready ho?" — ek loop mein. Simple hai par CPU ka time totally waste, kyunki wo bas ghoor raha hai.

Interrupt-driven mein CPU command de ke apna doosra kaam karne chala jaata hai. Jab device ready hota hai to wo CPU ko interrupt karta hai — ek bell bajata hai — aur CPU thodi der ke liye ISR (interrupt service routine) chalata hai, ek byte transfer karta hai, phir wapas apne kaam par. Yeh polling se behtar hai kyunki CPU wait nahi karta. Par dikkat: agar device bahut fast hai (har second laakhon bytes), to har byte par interrupt aayega aur overhead itna ho jayega ki yeh polling se bhi bura ho jata hai.

Isi liye DMA (Direct Memory Access) aata hai. Ek alag hardware controller hota hai jo pura block data directly device aur memory ke beech move karta hai — CPU ko ek-ek byte copy nahi karna padta. CPU sirf shuru mein DMA ko setup karta hai (address, count) aur ek hi interrupt aata hai end mein jab pura block done ho jaye. Yaad rakho: DMA CPU ko bilkul free nahi karta — bus share hota hai, to kabhi-kabhi CPU ek cycle ruk jaata hai, ise cycle stealing kehte hain. Mnemonic yaad rakho: P-I-D = Pester, Interrupt, Delegate — neeche jaate jaate CPU ka kaam kam hota jaata hai.

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

WHY do we need any of this?

1. Polling (Programmed I/O)

2. Interrupt-driven I/O

3. DMA (Direct Memory Access)

Putting it together — Forecast then Verify

Flashcards

Connections

Concept Map

Hinglish (regional understanding)

Go deeper — visual, from zero

Test yourself — Operating Systems

Connections