在Linux 2.6中,有四種關(guān)于IO的調(diào)度算法,下面綜合小結(jié)一下:
1) NOOP
NOOP算法的全寫為No Operation。該算法實現(xiàn)了最最簡單的FIFO隊列，所有IO請求大致按照先來后到的順序進行操作。之所以說“大致”，
原因是NOOP在FIFO的基礎(chǔ)上還做了相鄰IO請求的合并，并不是完完全全按照先進先出的規(guī)則滿足IO請求。NOOP假定I/O請求由驅(qū)動程序或者設(shè)
備做了優(yōu)化或者重排了順序(就像一個智能控制器完成的工作那樣)。在有些SAN環(huán)境下，這個選擇可能是最好選擇。Noop 對于 IO 不那么操
心，對所有的 IO請求都用 FIFO 隊列形式處理，默認認為 IO 不會存在性能問題。這也使得 CPU 也不用那么操心。www.linuxidc.com當然
，對于復(fù)雜一點的應(yīng)用類型，使用這個調(diào)度器，用戶自己就會非常操心。
2) Deadline scheduler
DEADLINE在CFQ的基礎(chǔ)上，解決了IO請求餓死的極端情況。除了CFQ本身具有的IO排序隊列之外，DEADLINE額外分別為讀IO和寫IO提供了FIFO
隊列。讀FIFO隊列的最大等待時間為500ms，寫FIFO隊列的最大等待時間為5s。FIFO隊列內(nèi)的IO請求優(yōu)先級要比CFQ隊列中的高，，而讀FIFO
隊列的優(yōu)先級又比寫FIFO隊列的優(yōu)先級高。優(yōu)先級可以表示如下：
FIFO(Read) > FIFO(Write) > CFQ
deadline 算法保證對于既定的 IO 請求以最小的延遲時間，從這一點理解，對于 DSS 應(yīng)用應(yīng)該會是很適合的。
3) Anticipatory scheduler
CFQ和DEADLINE考慮的焦點在于滿足零散IO請求上。對于連續(xù)的IO請求，比如順序讀，并沒有做優(yōu)化。為了滿足隨機IO和順序IO混合的場景，
Linux還支持ANTICIPATORY調(diào)度算法。ANTICIPATORY的在DEADLINE的基礎(chǔ)上，為每個讀IO都設(shè)置了6ms 的等待時間窗口。如果在這6ms內(nèi)OS收
到了相鄰位置的讀IO請求，就可以立即滿足
Anticipatory scheduler（as) 曾經(jīng)一度是 Linux 2.6 Kernel 的 IO scheduler 。Anticipatory 的中文含義是”預(yù)料的, 預(yù)想的”, 這個
詞的確揭示了這個算法的特點，簡單的說，有個 IO 發(fā)生的時候，如果又有進程請求 IO 操作，則將產(chǎn)生一個默認的 6 毫秒猜測時間，猜測
下一個 進程請求 IO 是要干什么的。這對于隨即讀取會造成比較大的延時，對數(shù)據(jù)庫應(yīng)用很糟糕，而對于 Web Server 等則會表現(xiàn)的不錯。
這個算法也可以簡單理解為面向低速磁盤的，因為那個”猜測”實際上的目的是為了減少磁頭移動時間。
4）CFQ
CFQ算法的全寫為Completely Fair Queuing。該算法的特點是按照IO請求的地址進行排序，而不是按照先來后到的順序來進行響應(yīng)。
在傳統(tǒng)的SAS盤上，磁盤尋道花去了絕大多數(shù)的IO響應(yīng)時間。CFQ的出發(fā)點是對IO地址進行排序，以盡量少的磁盤旋轉(zhuǎn)次數(shù)來滿足盡可能多的
IO請求。在CFQ算法下，SAS盤的吞吐量大大提高了。但是相比于NOOP的缺點是，先來的IO請求并不一定能被滿足，可能會出現(xiàn)餓死的情況。
Completely Fair Queuing （cfq, 完全公平隊列) 在 2.6.18 取代了 Anticipatory scheduler 成為 Linux Kernel 默認的 IO scheduler
。cfq 對每個進程維護一個 IO 隊列，各個進程發(fā)來的 IO 請求會被 cfq 以輪循方式處理。也就是對每一個 IO 請求都是公平的。這使得
cfq 很適合離散讀的應(yīng)用(eg: OLTP DB)。我所知道的企業(yè)級 Linux 發(fā)行版中，SUSE Linux 好像是最先默認用 cfq 的.
查看和修改IO調(diào)度器的算法非常簡單。假設(shè)我們要對sda進行操作，如下所示：
cat /sys/block/sda/queue/scheduler
echo “cfq” > /sys/block/sda/queue/scheduler
總結(jié):
1 CFQ和DEADLINE考慮的焦點在于滿足零散IO請求上。對于連續(xù)的IO請求，比如順序讀，并沒有做優(yōu)化。為了滿足隨機IO和順序IO混合的場景
，Linux還支持ANTICIPATORY調(diào)度算法。ANTICIPATORY的在DEADLINE的基礎(chǔ)上，為每個讀IO都設(shè)置了6ms的等待時間窗口。如果在這6ms內(nèi)OS收
到了相鄰位置的讀IO請求，就可以立即滿足。
IO調(diào)度器算法的選擇，既取決于硬件特征，也取決于應(yīng)用場景。
在傳統(tǒng)的SAS盤上，CFQ、DEADLINE、ANTICIPATORY都是不錯的選擇；對于專屬的數(shù)據(jù)庫服務(wù)器，DEADLINE的吞吐量和響應(yīng)時間都表現(xiàn)良好。
然而在新興的固態(tài)硬盤比如SSD、Fusion IO上，最簡單的NOOP反而可能是最好的算法，因為其他三個算法的優(yōu)化是基于縮短尋道時間的，而
固態(tài)硬盤沒有所謂的尋道時間且IO響應(yīng)時間非常短。
2 對于數(shù)據(jù)庫應(yīng)用, Anticipatory Scheduler 的表現(xiàn)是最差的。Deadline 在 DSS 環(huán)境表現(xiàn)比 cfq 更好一點，而 cfq 綜合來看表現(xiàn)更好一
些。這也難怪 RHEL 4 默認的 IO 調(diào)度器設(shè)置為 cfq. 而 RHEL 4 比 RHEL 3，整體 IO 改進還是不小的。