一、原理
Deadline調度器對一個請求的多方面特性進行權衡來進行調度，以期即能滿足塊設備扇區的順尋訪問又兼顧到一個請求不會在隊列中等待太久導致餓死。試想當應用程序頻繁訪問文件的一部分而此時如果有另一個遠端的請求，那麼這個請求將會在很長一段時間內得不到響應，這顯然是不合理的。Deadline調度器為了兼顧這兩個方面，引入了四個隊列，這四個隊列可分為兩類，每一類都由讀和寫兩種隊列組成。一類隊列用來對請求按起始扇區序號進行排序，通過紅黑樹來組織，稱為sort_list；另一類對請求按它們的生成時間進行排序，由鏈表來組織，稱為fifo_list。
二、batching
每當確定了一個傳輸方向(讀或寫)，那麼將會從相應的sort_list中將一批連續請求dispatch到requst_queue的請求隊列裡，具體的數目由fifo_batch來確定。只有下面三種情況才會導致一次批量傳輸的結束：
1.對應的sort_list中已經沒有請求了
2.下一個請求的扇區不滿足遞增的要求
3.上一個請求已經是批量傳輸的最後一個請求了。
三、deadline和dispatch
所有的請求在生成時都會被賦上一個期限值(根據jiffies)，並按期限值排序在fifo_list中，讀請求的期限時長默認為為500ms，寫請求的期限時長默認為5s，可以看出內核對讀請求是十分偏心的，其實不僅如此，在deadline調度器中，還定義了一個starved和writes_starved，writes_starved默認為2，可以理解為寫請求的饑餓線，內核總是優先處理讀請求，starved表明當前處理的讀請求批數，只有starved超過了writes_starved後，才會去考慮寫請求。因此，假如一個寫請求的期限已經超過，該請求也不一定會被立刻響應，因為讀請求的batch還沒處理完，即使處理完，也必須等到starved超過writes_starved才有機會被響應。為什麼內核會偏袒讀請求？這是從整體性能上進行考慮的。讀請求和應用程序的關系是同步的，因為應用程序要等待讀取的內容完畢，才能進行下一步工作，因此讀請求會阻塞進程，而寫請求則不一樣，應用程序發出寫請求後，內存的內容何時寫入塊設備對程序的影響並不大，所以調度器會優先處理讀請求。
