Interrupt Handling for I/O
請看 Interrupt 有關於 Interrupt 的詳細介紹
Basic Concept
Interrupt-driven I/O 是讓 device controller 在需要 CPU attention 時主動通知 CPU 的機制。和 polling 相比，CPU 不必一直讀 status register 等 device ready；device 完成輸入、輸出、或發生 error 時，controller 透過 interrupt-request line 發出訊號，CPU 再暫停目前執行流進入 interrupt handler。
簡化流程是：
- Device driver 啟動 I/O request。
- Controller 操作 device。
- I/O 完成或出錯時，controller raise interrupt。
- CPU 在 instruction boundary 偵測到 interrupt，保存目前狀態。
- CPU 根據 interrupt vector 找到 interrupt handler。
- Handler 處理 device event，清除 interrupt，必要時喚醒等待中的 process。
- CPU restore state，回到原本執行流。
Interrupt Vector and Dispatch
現代系統可能有很多 interrupt source，如果每次 interrupt 都讓同一個 handler 去問所有 device「是不是你？」，會很沒效率。因此 CPU 通常使用 interrupt vector：interrupt 帶有一個 Interrupt number，CPU 用它查表找到對應 handler 的 address，此 address 稱為 Interrupt vector
如果 device 數量比 vector table entry 多，OS 可能使用 interrupt chaining：一個 vector entry 指向一串 handlers，interrupt 發生時依序詢問，直到找到能處理該 event 的 handler。這是在巨大 table 和單一 handler 全面搜尋之間的折衷。
Interrupt and System Performance
Interrupt 不是免費的。每次 interrupt 都需要 state save/restore、進入 handler、可能造成 context switch。因此在 I/O rate 很高時，interrupt overhead 可能變成瓶頸。這也是為什麼一些 high-throughput device driver 會在低流量時使用 interrupt，在高流量時切換成 polling。
核心 trade-off
Interrupt 避免 CPU 長時間 busy waiting，但把成本轉成 interrupt dispatch、handler execution、state restore、以及可能的 context switch。是否划算取決於 event 頻率與每次等待時間