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

Galat — ek aisi device ke liye jo almost hamesha ready hoti hai aur bahut fast hoti hai, ek single poll turant succeed ho sakta hai, aur yeh fixed interrupt-setup + context-save overhead se behtar hai. Polling tabhi cycles waste karti hai jab device CPU ke relative slow ho.

Waiting ke liye mostly sahi hai, lekin interrupts apna khud ka cost laate hain: har interrupt ek context save/restore force karta hai. High data rates par yeh overhead us polling waste se zyada ho sakta hai jise usne replace kiya tha.

Galat — CPU bytes copy karne se free ho jaata hai, lekin DMA aur CPU memory bus share karte hain. Jab DMA bus leta hai (cycle stealing) toh CPU us cycle ke liye stall ho sakta hai, isliye yeh poori tarah contention-free nahi hai.

Galat — DMA sabse complex hai phir bhi ek keyboard ke liye overkill hai jo har 200 ms mein ek byte bhejti hai; setup cost single-byte payload se kaafi zyada hai. "Best" ka matlab device ki rate aur block size se match karna hai, hardware maximize karna nahi.

Sahi — yahi toh poora point hai. Device ka idle time CPU ke doosre kaam ke saath overlap hota hai; CPU sirf briefly rukta hai ISR run karne ke liye jab device signal deta hai ki ready hai.

Galat — ek single byte ke liye, DMA ko phir bhi programming chahiye (address, count, direction) aur ek completion interrupt, jo ek plain ISR se zyada kaam hai. DMA tabhi jeetta hai jab block bada hota jaata hai.

Sahi — polling software mein pure busy-wait hai; koi hardware interrupt line nahi, koi vector lookup nahi, koi ISR nahi. Yahi simplicity exactly wajah hai ki ise zero extra hardware chahiye.

Galat — unhe dono tarafon se access kiya ja sakta hai. Memory-mapped I/O vs Port-mapped I/O dekho: memory-mapped unhe ordinary addresses ki tarah expose karta hai; port-mapped special I/O instructions use karta hai. Teeno techniques dono ke saath kaam karti hain.

Galat — DMA exactly ek interrupt raise karta hai, completion par (count 0 tak pahunchne par). N ka per-byte interrupt count interrupt-driven I/O ka hai, DMA ka nahi.

Galat — loop spin karta hai, wait karte hue $T_{dev}/t_{poll}$ iterations execute karta hai, phir N byte-moves karta hai. Yeh O(N) moves hai plus ek bada wasted-poll term, O(1) nahi.

Galat — ek high-rate device ke liye (millions of bytes/sec) har byte par ek interrupt matlab millions of ISR invocations; accumulated overhead polling waste se zyada ho sakta hai, interrupts ko worse bana deta hai. Yahi gap DMA fill karta hai.

Galat — ISR isliye run hota hai kyunki device already ready hai (usne interrupt raise kiya). Status par busy-waiting polling technique hai; ise ISR ke andar rakhna interrupts ka purpose khatam kar deta hai.

Galat — DMA ko phir bhi ek completion interrupt chahiye taaki CPU ko pata chale ki block khatam hua. Uski efficiency N ki jagah ek interrupt raise karne se aati hai, zero raise karne se nahi.

Galat — yeh memory-bus cycles churaata hai, registers nahi. Jab DMA ko ek word move karne ke liye bus chahiye, woh briefly bus le leta hai aur CPU us cycle ke liye stall ho sakta hai; registers untouched rehte hain.

Zaroori nahi — device ko phir bhi $T_{dev}$ lagega ready hone mein, kisi bhi tarah se. Interrupts device ko speed nahi dete; yeh CPU ko usi wait ke dauran doosra kaam karne ke liye free karte hain. Transfer completion time device se bound hoti hai, CPU technique se nahi.

Kyunki CPU back-to-back poll loop run karta hai aur har last se pehle ka iteration device ko not-ready paata hai, isliye almost saare $T_{dev}/t_{poll}$ iterations pure waste hain. CPU utilization and throughput dekho.

Har interrupt ek fixed $t_{int}$ cost force karta hai — context save, vector jump, ISR run, aur context restore. Ise millions of units per second se multiply karo aur $t_{int}$ dominate karne lagta hai, real kaam bhukha reh jaata hai.

Controller generic hardware hai; ise is transfer ke liye source/destination address, byte count, aur direction chahiye. Us setup ke bina use pata nahi hoga kya move karna hai ya kahan.

ISR usi CPU par run hota hai aur registers/flags ko clobber karta hai. Interrupted program ki state save karna (dekho Context switching) CPU ko exactly wahan restore aur resume karne deta hai jahan ISR return hone ke baad chhoda tha.

DMA poore block ko autonomous hardware ko de deta hai, isliye CPU work (setup + ek completion ISR) N se regardless constant rehta hai. Interrupt-driven har unit par ek ISR pay karta hai, isliye CPU work N ke saath linearly badhta hai.

Sahi technique device ki data rate aur block size par depend karti hai — fast-always-ready ke liye polling; slow rare events ke liye interrupts; bade fast blocks ke liye DMA. Driver apne specific hardware ke liye woh decision encode karta hai.

Ek disk bade contiguous blocks (thousands of bytes) move karta hai jahan fixed setup cost kaafi bytes mein amortise ho jaati hai; ek keyboard har rare keystroke par ek single byte deliver karta hai, isliye DMA ka setup payload se zyada hota hai — interrupt-driven better fit karta hai. Disk Scheduling dekho.

Polling — pehla status read already "ready" dikhata hai, isliye zero wasted spinning hai aur koi interrupt/DMA setup overhead nahi. Yeh classic "device almost always ready" case hai.

Yeh ya toh pending held hoti hai (masked) ya, agar higher priority ho, pre-empt kar sakti hai — interrupt controller ke priority/masking rules se handle hota hai. Baat yeh hai ki interrupts nest ya queue ho sakti hain; ISR ko re-triggering se bachne ke liye return se pehle apna source clear karna hoga. Interrupts and ISR dekho.

Roughly interrupt-driven ≈ polling (agar device quick ho) < DMA — ek akele byte ke liye DMA ka setup + completion interrupt sabse zyada kaam hai, usual large-block ranking ko ulta kar deta hai.

Nahi — jaise $T_{dev}$ chhota hota hai, polling waste $T_{dev}/t_{poll}\cdot t_{poll}=T_{dev}\to 0$, isliye bachane ke liye kuch nahi, jabki interrupts abhi bhi $t_{int}$ cost karte hain. Is limit mein polling jeetti hai.

Effectively 0% useful work — CPU "busy" hai lekin sirf status register par spin kar raha hai, kuch productive nahi kar raha jabki device ready nahi hai.

Haan — frequent cycle stealing kaafi bus cycles chura leta hai, CPU ke apne memory accesses ko stall karta hai, isliye effective throughput dip ho sakti hai. Yeh copying se kaafi behtar hai, lekin free nahi hai.

Request tab tak pending rehti hai jab tak interrupts re-enable nahi ho jaate; phir CPU use service karta hai. Masking delay karta hai, request discard nahi karta — device line asserted hold karta hai.