i/o調度策略對於實際性能影響的概括。我簡單說明最極端的兩個，另外三個就是介於這兩個之間的策略。
noop是最簡單的i/o調度策略，本質上就是先來先服務，意思就是哪個進程先請求i/o系統就先為哪個進程服務，有最好的連續存取性能（具體原因下面講），
bfq會均衡考慮各進程i/o請求的任務量，適當調整完成i/o請求的順序（也就是說服務順序和請求順序不壹樣），保進程在最短時間內能得到i/o響應（但不保證每
次響應都能完成），也就是有最好的隨機存取，延時低。
noop不考慮i/o請求的任務量（通俗點說就是不考慮讀寫的文件是大還是小），按照i/o請求的順序依次進行服務。這種策略在pc上的執行過程中主要有兩個問題，
第壹個是i/o請求任務量很大（要讀寫的某個文件很大）造成其他i/o請求長期得不到響應，第二個是相鄰兩次的i/o請求涉及的文件在磁盤上的物理位置較遠造成處理這i/o請求時磁頭需要頻繁移動導致性能嚴重降低。
第壹個應該很好理解，i/o任務量不管大小依次排隊，當處理到壹個很大的任務時，系統將壹直處理下去，後面的請求就得不到響應了，
第二個問題舉個例子，有4個相鄰的i/o請求分別涉及1、2、3、4這四個文件，
而1、2、3、4分別位於磁盤的內圈、外圈、內圈、外圈，也是說處理這4個請求時磁盤上的磁頭必須先移到內圈，
然後移到外圈，接著移到內圈再移到外圈，如此反復導致大量的時間用於移動磁頭造成性能降低。
反過來看手機，壹般手機上的i/o任務都不會很大，很少有需要連續讀幾百M甚至更大文件的情況，即便要讀通常也是正在玩遊戲需要讀數據文件（我相信手機上不會有壹邊上網聊qq，手機後臺還有個程序需要連續讀幾百M文件的情況），這時用戶通常希望系統盡快把文件讀完從而繼續玩遊戲。
由於noop在處理大任務時會使後續的i/o請求得不到響應，因此具有較好的連續性能，這個特點正好滿足了上面這種用戶的求。
關於上面說的第二個問題，由於手機上用的是閃存芯片，也就不存在磁頭移動的問題，像其他策略那樣考慮磁頭的移動問題對於采用閃存芯片的存儲介質完全是浪費，所以對於隨機性能很好的閃存芯片來說noop是最好的i/o調度策略。
下面看bfq，bfq指的是budgetfair queuing，從名字上就能看出來這個策略對於各i/o請求是公平的（fair），不會有上面說的noop的第壹種問題。
這裏指的公平就是盡量使各進程的i/o請求都能得到盡快響應不會長期擱置，但因為系統資源有限，所以只能保證盡快響應但不保證可以盡快完成。
不難看出bfq適合多進程同時發出多i/o請求的狀況，因為它不會像noop那樣無視後續的i/o請求。直觀的看就是手機程序開的很多時系統還能對各進程有不錯的響應速度，
這就是我說為什麽bfq適合多進程，可以均衡協調前後臺任務性能的原因。bfq實際上是cfq的改進，具體算法比較復雜我就不說了，有興趣的可以自行google
來源:/p/1698433177?
簡而言之:
noop-sio-deadline-cfq-bfq 的意思是:
手機上的操作引起的任務看作是去漢堡店吃快餐, 這樣, 全部任務都看成是在櫃臺排隊的客人,
noop 就是誰先來的, 就給誰先服務, 不管第壹個人的要求多麽奇葩, 磨蹭了多長時間,都壹定要把他服務完了再說.
cfq 就是先看看排隊的人群裏, 有沒有人只買個圓筒就走的, 就用幾秒時間把這些人先打發走. 盡量以最有效率, 最快的方式把這隊人服務完. bfq是cfq的改良版.
剩余幾個介於noop和bfq之間
其中的deadline 是壹刀切的態度, 不管誰來了, 都只給他特定時間點菜, 如10秒鐘的點菜時間, 10秒過了, 他還沒想好點什麽菜,或者還有菜沒點完, 那就先把他已經點好菜送給他吃, 並且, 讓他回到隊伍的最後面, 繼續排隊來點那些還沒有點完的菜.