概述
由於對multi-quque的IO調度算法不太熟悉，爲了避免誤人子弟，本文暫時只會介紹如何選擇single-queue的IO調度算法。等將來對multi-queue有充分認識後再補充。
如果不清楚什麼是single-queue和multi-queue，可以看這文章《塊層介紹 第二篇: request層》
最新版本的Linux內核已經完全切到multi-queue架構，因此single-queue下的IO調度算法在最新內核可能已經銷聲匿跡了。但實際上，multi-queue的IO調度算法很大程度上參考了single-queue的IO調度算法，因此一定程度上可以類推。
| 單隊列調度算法 | 多隊列調度算法 |
|---|---|
| deadline | mq-deadline |
| cfq | bfq |
| noop | none |
| kyber |
爲什麼需要IO調度呢？在最開始的時候，Linux存儲在磁盤上。磁盤盤片高速旋轉，通過磁臂的移動讀取數據。磁臂的移動是物理上的機械上的移動，它無法瞬移，這速度是很慢的。如果我們讀取的數據位置很隨機，一會在A地點，一會在隔着老遠的B地點，移動的時間就全做了無用功，這也就是我們說的隨機讀寫性能慢的原因。如果讀取的數據地址是連續的，即使不是連續的也是地址接近的，那麼移動磁臂的時間損耗就少了。在最開始，IO調度的作用就是爲了合併相近的IO請求，減少磁臂的移動損耗。
單隊列調度算法
單隊列架構下，常用的調度算法有3種：noop，deadline和cfq
noop
noop只會對請求做一些簡單的排序，其本質就是一個FIFO的隊列，只會簡單地合併臨近的IO請求後，本質還是按先來先處理的原則提交給磁盤。
根據它的原理，我們可以發現它傾向於餓死讀利於寫，爲什麼呢？異步寫是把數據直接放到page cache的，也就意味着可以通過page cache緩存大量的寫數據，再一次性往下提交IO請求。而讀呢？讀一般是同步的，也就意味着必須在讀完一筆後再讀下一筆，兩次讀之間是可能被寫請求插足的。
cfq
CFQ算法會爲每個進程單獨創建一個隊列，保存該進程產生的所有IO請求。不同隊列之間按時間片來調度，以此保證每個進程都能很好的分到I/O帶寬。這IO的時間片調度跟進程調度是非常相似的，進程調度有進程優先級，而IO調度也有IO優先級。
CFQ的出發點是對IO地址進行排序，以儘量少的磁盤旋轉次數來滿足儘可能多的IO請求。在CFQ算法下，SAS盤的吞吐量大大提高了。但是相比於NOOP的缺點是，先來的IO請求並不一定能被滿足，可能會出現餓死的情況。
當一個同步隊列中的請求不足一定數量時，這個設備可以空閒一會，即使其它隊列裏可能有請求等待處理。通常，同步請求之間在磁盤上的物理位置是連續的，所以讓磁盤稍等一會來接收更多連續的請求，這樣做可以提高吞吐量。
deadline
deadline確保請求在一個用戶可配置的時間內得到響應，避免請求餓死。其分別爲讀IO和寫IO提供不同的FIFO隊列，讀FIFO隊列的最大等待時間是500ms，寫FIFO隊列的最大等待時間是5s。deadline會把提交時間相近的請求放在一批。在同一批中，請求會被排序。當一批請求達到了大小上限或着定時器超時，這批請求就會提交到設備隊列上去。
選擇調度算法
網上的資料基本都給出類似的結論：
- 對閃存等存儲介質，優先使用
noop調度算法 - 個人PC使用
cfq調度算法 - 對IO壓力比較重，且功能比較單一的場景，例如數據庫服務器，使用
deadline調度算法
可惜的是網上的資料基本是相互複製，很少能講清楚這麼選擇的原因。
-
爲什麼閃存等介質，例如固態硬盤SSD，要選擇
noop調度算法？
noop先來先處理的做法對磁盤來說時間損耗非常大，大量浪費了磁盤磁臂移動的時間。但是對閃存設備，例如mmc、nand等，卻是最好的選擇，因爲閃存設備的物理結構跟磁盤完全不同，其通過一些規範的命令即可讀取數據，沒有磁臂這東西。此時IO調度算法裏的排序、合併其實沒太大意義，反而浪費了CPU和內存。 -
爲什麼個人PC要用
cfq調度算法？
在個人PC的場景上，往往需要打開大量的程序，創建大量的進程。每個進程都可能有IO的請求。在這場景下，我們需要的是如何確保不同進程或進程組間IO資源使用的公平性。總不能因爲A進程要拷貝電影，獨佔了IO資源，導致B進程無法打開文檔不是？
cfq調度算法是以進程之間公平享用IO資源爲出發點設計的，所以，個人PC建議使用cfq調度算法，但cfq調度算法不僅僅用於個人PC，準確來說，cfq調度算法適用於有大量進程的多用戶系統。 -
爲什麼
deadline調度算法適用於數據庫？
deadline是一種以提高機械硬盤吞吐量爲思考出發點的調度算法，所以準確來說，deadline調度算法適用於IO壓力比較重，且業務功能單一的場景，而數據庫毫無疑問是最爲匹配的場景了。
根據以上描述的不同調度算法的特點，我們再根據自己的場景挑選合適的IO調度算法就好，靈活點，自信點，不要別人說啥就選啥，別人沒說就一臉懵逼。
多隊列調度算法
先留坑，以後填