linux io 演算法

在Linux 2.6中,有四種關於IO的調度演算法,下面綜合小結一下:
1) NOOP
NOOP演算法的全寫為No Operation。該演算法實現了最最簡單的FIFO隊列，所有IO請求大致按照先來後到的順序進行操作。之所以說“大致”，原因是NOOP在FIFO的 基礎上還做了相鄰IO請求的合并，並不是完完全全按照先進先出的規則滿足IO請求。NOOP假定I/O請求由驅動程式或者裝置做了最佳化或者重排了順序(就 像一個智能控制器完成的工作那樣)。在有些SAN環境下，這個選擇可能是最好選擇。Noop 對於 IO 不那麼操心，對所有的 IO請求都用 FIFO 隊列形式處理，預設認為 IO 不會存在效能問題。這也使得 CPU 也不用那麼操心。當然，對於複雜一點的應用類型，使用這個調度器，使用者自己就會非常操心。

2) Deadline scheduler
DEADLINE在CFQ的基礎上，解決了IO請求餓死的極端情況。除了CFQ本身具有的IO排序隊列之外，DEADLINE額外分別為讀IO和寫 IO提供了FIFO隊列。讀FIFO隊列的最大等待時間為500ms，寫FIFO隊列的最大等待時間為5s。FIFO隊列內的IO請求優先順序要比CFQ隊 列中的高，，而讀FIFO隊列的優先順序又比寫FIFO隊列的優先順序高。優先順序可以表示如下：
FIFO(Read) > FIFO(Write) > CFQ
deadline 演算法保證對於既定的 IO 請求以最小的延遲時間，從這一點理解，對於 DSS 應用應該會是很適合的。
3) Anticipatory scheduler
CFQ和DEADLINE考慮的焦點在於滿足零散IO請求上。對於連續的IO請求，比如順序讀，並沒有做最佳化。為了滿足隨機IO和順序IO混合的場 景，Linux還支援ANTICIPATORY調度演算法。ANTICIPATORY的在DEADLINE的基礎上，為每個讀IO都設定了6ms 的等待時間視窗。如果在這6ms內OS收到了相鄰位置的讀IO請求，就可以立即滿足Anticipatory scheduler（as) 曾經一度是 Linux 2.6 Kernel 的 IO scheduler 。Anticipatory 的中文含義是”預料的, 預想的”, 這個詞的確揭示了這個演算法的特點，簡單的說，有個 IO 發生的時候，如果又有進程請求 IO 操作，則將產生一個預設的 6 毫秒猜測時間，猜測下一個 進程請求 IO 是要幹什麼的。這對於隨即讀取會造成比較大的延時，對資料庫應用很糟糕，而對於 Web Server 等則會表現的不錯。
這個演算法也可以簡單理解為面向低速磁碟的，因為那個”猜測”實際上的目的是為了減少磁頭移動時間。
4）CFQ
CFQ演算法的全寫為Completely Fair Queuing。該演算法的特點是按照IO請求的地址進行排序，而不是按照先來後到的順序來進行響應。
在傳統的SAS盤上，磁碟尋道花去了絕大多數的IO回應時間。CFQ的出發點是對IO地址進行排序，以盡量少的磁碟旋轉次數來滿足儘可能多的IO請 求。在CFQ演算法下，SAS盤的輸送量大大提高了。但是相比於NOOP的缺點是，先來的IO請求並不一定能被滿足，可能會出現餓死的情況。
Completely Fair Queuing （cfq, 完全公平隊列) 在 2.6.18 取代了 Anticipatory scheduler 成為 Linux Kernel 預設的 IO scheduler 。cfq 對每個進程維護一個 IO 隊列，各個進程發來的 IO 請求會被 cfq 以輪循方式處理。也就是對每一個 IO 請求都是公平的。這使得cfq 很適合離散讀的應用(eg: OLTP DB)。我所知道的企業級 Linux 發行版中，SUSE Linux 好像是最先預設用 cfq 的.
查看和修改IO調度器的演算法非常簡單。假設我們要對sda進行操作，如下所示：
cat /sys/block/sda/queue/scheduler
echo “cfq” > /sys/block/sda/queue/scheduler
總結:
1 CFQ和DEADLINE考慮的焦點在於滿足零散IO請求上。對於連續的IO請求，比如順序讀，並沒有做最佳化。為了滿足隨機IO和順序IO混合的場 景，Linux還支援ANTICIPATORY調度演算法。ANTICIPATORY的在DEADLINE的基礎上，為每個讀IO都設定了6ms的等待時間 視窗。如果在這6ms內OS收到了相鄰位置的讀IO請求，就可以立即滿足。
IO調度器演算法的選擇，既取決於硬體特徵，也取決於應用情境。
在傳統的SAS盤上，CFQ、DEADLINE、ANTICIPATORY都是不錯的選擇；對於專屬的資料庫伺服器，DEADLINE的輸送量和回應時間都表現良好。
然而在新興的固態硬碟比如SSD、Fusion IO上，最簡單的NOOP反而可能是最好的演算法，因為其他三個演算法的最佳化是基於縮短尋道時間的，而固態硬碟沒有所謂的尋道時間且IO回應時間非常短。
2 對於資料庫應用, Anticipatory Scheduler 的表現是最差的。Deadline 在 DSS 環境表現比 cfq 更好一點，而 cfq 綜合來看錶現更好一些。這也難怪 RHEL 4 預設的 IO 調度器設定為 cfq. 而 RHEL 4 比 RHEL 3，整體 IO 改進還是不小的。
http://www.linuxpx.cn/Linux/Linux_2271.html
Linux核心塊裝置I/O子系統
http://www.cnblogs.com/zhenjing/archive/2012/06/20/linux_writeback.html