Deadline IO 排程器可調引數¶
本小檔案旨在闡述 Deadline IO 排程器的工作原理。特別是，它將闡明可能對高階使用者有用的暴露出的可調引數的含義。
選擇 IO 排程器¶
有關如何為每個裝置選擇 IO 排程器的資訊，請參閱切換排程器。
read_expire（毫秒）¶
Deadline IO 排程器的目標是嘗試保證請求的啟動服務時間。由於我們主要關注讀取延遲，因此這是可調的。當讀取請求首次進入 IO 排程器時，它將被分配一個截止時間，該時間是當前時間加上以毫秒為單位的 read_expire 值。
write_expire（毫秒）¶
與上述 read_expire 類似，但適用於寫入。
fifo_batch（請求數量）¶
請求按特定資料方向（讀取或寫入）分組為批次，並按扇區遞增順序提供服務。為限制額外尋道，只在批次之間檢查截止時間。fifo_batch 控制每個批次的最大請求數量。
此引數調整了每個請求的延遲和總吞吐量之間的平衡。當低延遲是主要考慮因素時，值越小越好（其中值為 1 時，表現為先來先服務行為）。增加 fifo_batch 通常會提高吞吐量，但會犧牲延遲的穩定性。
writes_starved（排程次數）¶
當我們需要將請求從 IO 排程器佇列移動到塊裝置排程佇列時，我們總是優先處理讀取請求。然而，我們也不希望無限期地餓死寫入請求。因此，writes_starved 控制我們優先處理讀取請求而不是寫入請求的次數。當達到 writes_starved 次後，我們將根據與讀取相同的標準排程一些寫入請求。
front_merges（布林值）¶
有時，一個新請求進入 IO 排程器，而該請求與佇列中已有的請求是連續的。它可能接在該請求的尾部，也可能接在該請求的頭部。這分別被稱為“尾部合併候選項”或“頭部合併候選項”。由於檔案通常的佈局方式，尾部合併比頭部合併要常見得多。對於某些工作負載，您甚至可能知道花費時間嘗試頭部合併請求是浪費時間。將 front_merges 設定為 0 將停用此功能。頭部合併仍可能由於快取的 last_merge 提示而發生，但由於其成本幾乎為零，我們保留了此功能。當呼叫 IO 排程器合併函式時，我們只是停用了紅黑樹（rbtree）的前扇區查詢。
2002年11月11日, Jens Axboe <jens.axboe@oracle.com>