deadline
演算法維護
5個佇列，除了請求佇列以外，演算法還使用了四個佇列。其中兩個排序佇列分別包含讀請求和寫請求，這個佇列是按照起始扇區數來排序的。另外兩個最後期限佇列包含相同的讀和寫請求，只不過它們是根據其「最後期限」排序的。這兩個佇列的目的是為了避免請求餓死。因為電梯策略優先處理與上乙個處理請求最近的請求，因而就會對摸個請求忽略很長一段時間，這時就會發生這個情況。請求的最後期限本質上就是超時定時器，當請求被傳給電梯演算法是開始計時。預設情況下，
deadline
演算法讀請求的超時時間為
500ms
，而寫請求的超時時間為
5s。也就是說，
deadline
演算法讀請求優先於寫請求，因為讀請求通常阻塞發出請求的程序。而最後期限保證了排程程式照顧等待很長一段時間的那個請求，即使它位於排序佇列的末尾。
deadline
演算法核心資料結構如下：
struct deadline_data ;
sort_list
：按照request
中的sector
號大小，把每個
request
組織在以
sort_list
為根的紅黑樹中。這樣方便快速查詢。總共有讀寫兩棵樹。
fifo_list
：按照超時先後順尋，把
request
鏈入filo_list
，同樣也是分為讀寫兩個佇列。
因此，任何乙個
request
，在未提交給裝置的請求佇列之前，都會同時存在於以上兩個結構中。
next_rq:
指向sort_list
中的下乙個請求。
batching
：排程演算法可能連續提交多個請求，
batching
用於記錄當前連續提交的
request
數目。當
batching < fifo_batch
，都可以繼續進行連續提交。
starved:
提交讀request
而造成寫飢餓的次數。如果
starved
超過writes_starved
，則需要提交寫
request
，從而避免寫飢餓。
Linux IO排程層分析 1
linux io 排程程式是塊裝置 i o子系統的主要元件，它介於通用塊層和塊裝置驅動程式之間，所圖 2 1所示。當 linux 核心元件要讀寫一些資料時，並不是請求一發出，核心便立即執行該請求，而是將其推遲執行。延遲的設定是塊裝置效能的關鍵機制！當傳輸乙個新資料塊時，核心檢查能否通過擴充套件前乙個...
Linux I O排程策略
i o scheduler的作用就是為請求佇列裡面的io請求做乙個優化，以此達到提高系統吞吐量 縮短響應時間的目的。更改i o scheduler有兩種方式 1.sys block device name queue scheduler ioscheduler sys block device na...
修改Linux IO排程器
linux系統預設提供了三種io排程方式 原來系統中預設的排程方式是deadline，下面介紹如何更改預設排程機制。通過host cat sys block sdb queue scheduler sdb是我的系統安裝磁碟 noop deadline cfqhost 可以看到預設的排程方式是dead...