- 相關(guān)推薦
Linux系統基礎知識：IO調度
IO調度發(fā)生在Linux內核的IO調度層。這個(gè)層次是針對Linux的整體IO層次體系來(lái)說(shuō)的。從read()或者write()系統調用的角度來(lái)說(shuō)，Linux整體IO體系可以分為七層，它們分別是：
VFS層：虛擬文件系統層。由于內核要跟多種文件系統打交道，而每一種文件系統所實(shí)現的數據結構和相關(guān)方法都可能不盡相同，所以，內核抽象了這一層，專(zhuān)門(mén)用來(lái)適配各種文件系統，并對外提供統一操作接口。
文件系統層：不同的文件系統實(shí)現自己的操作過(guò)程，提供自己特有的特征，具體不多說(shuō)了，大家愿意的話(huà)自己去看代碼即可。
頁(yè)緩存層：負責真對page的緩存。
通用塊層：由于絕大多數情況的io操作是跟塊設備打交道，所以L(fǎng)inux在此提供了一個(gè)類(lèi)似vfs層的塊設備操作抽象層。下層對接各種不同屬性的塊設備，對上提供統一的Block IO請求標準。
IO調度層：因為絕大多數的塊設備都是類(lèi)似磁盤(pán)這樣的設備，所以有必要根據這類(lèi)設備的特點(diǎn)以及應用的不同特點(diǎn)來(lái)設置一些不同的調度算法和隊列。以便在不同的應用環(huán)境下有針對性的提高磁盤(pán)的讀寫(xiě)效率，這里就是大名鼎鼎的Linux電梯所起作用的地方。針對機械硬盤(pán)的各種調度方法就是在這實(shí)現的。
塊設備驅動(dòng)層：驅動(dòng)層對外提供相對比較高級的設備操作接口，往往是C語(yǔ)言的，而下層對接設備本身的操作方法和規范。
塊設備層：這層就是具體的物理設備了，定義了各種真對設備操作方法和規范。
有一個(gè)已經(jīng)整理好的Linux IO結構圖，非常經(jīng)典，一圖勝千言：
我們今天要研究的內容主要在IO調度這一層。它要解決的核心問(wèn)題是，如何提高塊設備IO的整體性能?這一層也主要是針對機械硬盤(pán)結構而設計的。眾所周知，機械硬盤(pán)的存儲介質(zhì)是磁盤(pán)，磁頭在盤(pán)片上移動(dòng)進(jìn)行磁道尋址，行為類(lèi)似播放一張唱片。這種結構的特點(diǎn)是，順序訪(fǎng)問(wèn)時(shí)吞吐量較高，但是如果一旦對盤(pán)片有隨機訪(fǎng)問(wèn)，那么大量的時(shí)間都會(huì )浪費在磁頭的移動(dòng)上，這時(shí)候就會(huì )導致每次IO的響應時(shí)間變長(cháng)，極大的降低IO的響應速度。磁頭在盤(pán)片上尋道的操作，類(lèi)似電梯調度，如果在尋道的過(guò)程中，能把順序路過(guò)的相關(guān)磁道的數據請求都“順便”處理掉，那么就可以在比較小影響響應速度的前提下，提高整體IO的吞吐量。這就是我們問(wèn)什么要設計IO調度算法的原因。在最開(kāi)始的時(shí)期，Linux把這個(gè)算法命名為L(cháng)inux電梯算法。
目前在內核中默認開(kāi)啟了三種算法，其實(shí)嚴格算應該是兩種，因為第一種叫做noop，就是空操作調度算法，也就是沒(méi)有任何調度操作，并不對io請求進(jìn)行排序，僅僅做適當的io合并的一個(gè)fifo隊列。
目前內核中默認的調度算法應該是cfq，叫做完全公平隊列調度。這個(gè)調度算法人如其名，它試圖給所有進(jìn)程提供一個(gè)完全公平的IO操作環(huán)境。它為每個(gè)進(jìn)程創(chuàng )建一個(gè)同步IO調度隊列，并默認以時(shí)間片和請求數限定的方式分配IO資源，以此保證每個(gè)進(jìn)程的IO資源占用是公平的，cfq還實(shí)現了針對進(jìn)程級別的優(yōu)先級調度，這個(gè)我們后面會(huì )詳細解釋。
查看和修改IO調度算法的方法是：
cfq是通用服務(wù)器比較好的IO調度算法選擇，對桌面用戶(hù)也是比較好的選擇。但是對于很多IO壓力較大的場(chǎng)景就并不是很適應，尤其是IO壓力集中在某些進(jìn)程上的場(chǎng)景。因為這種場(chǎng)景我們需要更多的滿(mǎn)足某個(gè)或者某幾個(gè)進(jìn)程的IO響應速度，而不是讓所有的進(jìn)程公平的使用IO，比如數據庫應用。
deadline調度(最終期限調度)就是更適合上述場(chǎng)景的解決方案。deadline實(shí)現了四個(gè)隊列，其中兩個(gè)分別處理正常read和write，按扇區號排序，進(jìn)行正常io的合并處理以提高吞吐量.因為IO請求可能會(huì )集中在某些磁盤(pán)位置，這樣會(huì )導致新來(lái)的請求一直被合并，可能會(huì )有其他磁盤(pán)位置的io請求被餓死。因此實(shí)現了另外兩個(gè)處理超時(shí)read和write的隊列，按請求創(chuàng )建時(shí)間排序，如果有超時(shí)的請求出現，就放進(jìn)這兩個(gè)隊列，調度算法保證超時(shí)(達到最終期限時(shí)間)的隊列中的請求會(huì )優(yōu)先被處理，防止請求被餓死。
不久前，內核還是默認標配四種算法，還有一種叫做as的算法(Anticipatory scheduler)，預測調度算法。一個(gè)高大上的名字，搞得我一度認為L(cháng)inux內核都會(huì )算命了。結果發(fā)現，無(wú)非是在基于deadline算法做io調度的之前等一小會(huì )時(shí)間，如果這段時(shí)間內有可以合并的io請求到來(lái)，就可以合并處理，提高deadline調度的在順序讀寫(xiě)情況下的數據吞吐量。其實(shí)這根本不是啥預測，我覺(jué)得不如叫撞大運調度算法，當然這種策略在某些特定場(chǎng)景差效果不錯。但是在大多數場(chǎng)景下，這個(gè)調度不僅沒(méi)有提高吞吐量，還降低了響應速度，所以?xún)群烁纱喟阉鼜哪J配置里刪除了。畢竟Linux的宗旨是實(shí)用，而我們也就不再這個(gè)調度算法上多費口舌了。
CFQ完全公平隊列
CFQ是內核默認選擇的IO調度隊列，它在桌面應用場(chǎng)景以及大多數常見(jiàn)應用場(chǎng)景下都是很好的選擇。如何實(shí)現一個(gè)所謂的完全公平隊列(Completely Fair Queueing)?首先我們要理解所謂的公平是對誰(shuí)的公平?從操作系統的角度來(lái)說(shuō)，產(chǎn)生操作行為的主體都是進(jìn)程，所以這里的公平是針對每個(gè)進(jìn)程而言的，我們要試圖讓進(jìn)程可以公平的占用IO資源。那么如何讓進(jìn)程公平的占用IO資源?我們需要先理解什么是IO資源。當我們衡量一個(gè)IO資源的時(shí)候，一般喜歡用的是兩個(gè)單位，一個(gè)是數據讀寫(xiě)的帶寬，另一個(gè)是數據讀寫(xiě)的IOPS。帶寬就是以時(shí)間為單位的讀寫(xiě)數據量，比如，100Mbyte/s。而IOPS是以時(shí)間為單位的讀寫(xiě)次數。在不同的讀寫(xiě)情境下，這兩個(gè)單位的表現可能不一樣，但是可以確定的是，兩個(gè)單位的任何一個(gè)達到了性能上限，都會(huì )成為IO的瓶頸。從機械硬盤(pán)的結構考慮，如果讀寫(xiě)是順序讀寫(xiě)，那么IO的表現是可以通過(guò)比較少的IOPS達到較大的帶寬，因為可以合并很多IO，也可以通過(guò)預讀等方式加速數據讀取效率。當IO的表現是偏向于隨機讀寫(xiě)的時(shí)候，那么IOPS就會(huì )變得更大，IO的請求的合并可能性下降，當每次io請求數據越少的時(shí)候，帶寬表現就會(huì )越低。從這里我們可以理解，針對進(jìn)程的IO資源的主要表現形式有兩個(gè)，進(jìn)程在單位時(shí)間內提交的IO請求個(gè)數和進(jìn)程占用IO的帶寬。其實(shí)無(wú)論哪個(gè)，都是跟進(jìn)程分配的IO處理時(shí)間長(cháng)度緊密相關(guān)的。
有時(shí)業(yè)務(wù)可以在較少I(mǎi)OPS的情況下占用較大帶寬，另外一些則可能在較大IOPS的情況下占用較少帶寬，所以對進(jìn)程占用IO的時(shí)間進(jìn)行調度才是相對最公平的。即，我不管你是IOPS高還是帶寬占用高，到了時(shí)間咱就換下一個(gè)進(jìn)程處理，你愛(ài)咋樣咋樣。所以，cfq就是試圖給所有進(jìn)程分配等同的塊設備使用的時(shí)間片，進(jìn)程在時(shí)間片內，可以將產(chǎn)生的IO請求提交給塊設備進(jìn)行處理，時(shí)間片結束，進(jìn)程的請求將排進(jìn)它自己的隊列，等待下次調度的時(shí)候進(jìn)行處理。這就是cfq的基本原理。
當然，現實(shí)生活中不可能有真正的“公平”，常見(jiàn)的應用場(chǎng)景下，我們很可能需要人為的對進(jìn)程的IO占用進(jìn)行人為指定優(yōu)先級，這就像對進(jìn)程的CPU占用設置優(yōu)先級的概念一樣。所以，除了針對時(shí)間片進(jìn)行公平隊列調度外，cfq還提供了優(yōu)先級支持。每個(gè)進(jìn)程都可以設置一個(gè)IO優(yōu)先級，cfq會(huì )根據這個(gè)優(yōu)先級的設置情況作為調度時(shí)的重要參考因素。優(yōu)先級首先分成三大類(lèi)：RT、BE、IDLE，它們分別是實(shí)時(shí)(Real Time)、最佳效果(Best Try)和閑置(Idle)三個(gè)類(lèi)別，對每個(gè)類(lèi)別的IO，cfq都使用不同的策略進(jìn)行處理。另外，RT和BE類(lèi)別中，分別又再劃分了8個(gè)子優(yōu)先級實(shí)現更細節的QOS需求，而IDLE只有一個(gè)子優(yōu)先級。
另外，我們都知道內核默認對存儲的讀寫(xiě)都是經(jīng)過(guò)緩存(buffer/cache)的，在這種情況下，cfq是無(wú)法區分當前處理的請求是來(lái)自哪一個(gè)進(jìn)程的。只有在進(jìn)程使用同步方式(sync read或者sync wirte)或者直接IO(Direct IO)方式進(jìn)行讀寫(xiě)的時(shí)候，cfq才能區分出IO請求來(lái)自哪個(gè)進(jìn)程。所以，除了針對每個(gè)進(jìn)程實(shí)現的IO隊列以外，還實(shí)現了一個(gè)公共的隊列用來(lái)處理異步請求。
當前內核已經(jīng)實(shí)現了針對IO資源的cgroup資源隔離，所以在以上體系的基礎上，cfq也實(shí)現了針對cgroup的調度支持。關(guān)于cgroup的blkio功能的描述，請看我之前的文章Cgroup – Linux的IO資源隔離�？偟膩�(lái)說(shuō)，cfq用了一系列的數據結構實(shí)現了以上所有復雜功能的支持，大家可以通過(guò)源代碼看到其相關(guān)實(shí)現，文件在源代碼目錄下的block/cfq-iosched.c。
CFQ設計原理
在此，我們對整體數據結構做一個(gè)簡(jiǎn)要描述：首先，cfq通過(guò)一個(gè)叫做cfq_data的數據結構維護了整個(gè)調度器流程。在一個(gè)支持了cgroup功能的cfq中，全部進(jìn)程被分成了若干個(gè)contral group進(jìn)行管理。每個(gè)cgroup在cfq中都有一個(gè)cfq_group的結構進(jìn)行描述，所有的cgroup都被作為一個(gè)調度對象放進(jìn)一個(gè)紅黑樹(shù)中，并以vdisktime為key進(jìn)行排序。vdisktime這個(gè)時(shí)間紀錄的是當前cgroup所占用的io時(shí)間，每次對cgroup進(jìn)行調度時(shí)，總是通過(guò)紅黑樹(shù)選擇當前vdisktime時(shí)間最少的cgroup進(jìn)行處理，以保證所有cgroups之間的IO資源占用“公平”。當然我們知道，cgroup是可以對blkio進(jìn)行資源比例分配的，其作用原理就是，分配比例大的cgroup占用vdisktime時(shí)間增長(cháng)較慢，分配比例小的vdisktime時(shí)間增長(cháng)較快，快慢與分配比例成正比。這樣就做到了不同的cgroup分配的IO比例不一樣，并且在cfq的角度看來(lái)依然是“公平“的。
選擇好了需要處理的cgroup(cfq_group)之后，調度器需要決策選擇下一步的service_tree。service_tree這個(gè)數據結構對應的都是一系列的紅黑樹(shù)，主要目的是用來(lái)實(shí)現請求優(yōu)先級分類(lèi)的，就是RT、BE、IDLE的分類(lèi)。每一個(gè)cfq_group都維護了7個(gè)service_trees，其定義如下：
struct cfq_rb_root service_trees[2][3];
struct cfq_rb_root service_tree_idle;
其中service_tree_idle就是用來(lái)給IDLE類(lèi)型的請求進(jìn)行排隊用的紅黑樹(shù)。而上面二維數組，首先第一個(gè)維度針對RT和BE分別各實(shí)現了一個(gè)數組，每一個(gè)數組中都維護了三個(gè)紅黑樹(shù)，分別對應三種不同子類(lèi)型的請求，分別是：SYNC、SYNC_NOIDLE以及ASYNC。我們可以認為SYNC相當于SYNC_IDLE并與SYNC_NOIDLE對應。idling是cfq在設計上為了盡量合并連續的IO請求以達到提高吞吐量的目的而加入的機制，我們可以理解為是一種“空轉”等待機制�？辙D是指，當一個(gè)隊列處理一個(gè)請求結束后，會(huì )在發(fā)生調度之前空等一小會(huì )時(shí)間，如果下一個(gè)請求到來(lái)，則可以減少磁頭尋址，繼續處理順序的IO請求。為了實(shí)現這個(gè)功能，cfq在service_tree這層數據結構這實(shí)現了SYNC隊列，如果請求是同步順序請求，就入隊這個(gè)service tree，如果請求是同步隨機請求，則入隊SYNC_NOIDLE隊列，以判斷下一個(gè)請求是否是順序請求。所有的異步寫(xiě)操作請求將入隊ASYNC的service tree，并且針對這個(gè)隊列沒(méi)有空轉等待機制。此外，cfq還對SSD這樣的硬盤(pán)有特殊調整，當cfq發(fā)現存儲設備是一個(gè)ssd硬盤(pán)這樣的隊列深度更大的設備時(shí)，所有針對單獨隊列的空轉都將不生效，所有的IO請求都將入隊SYNC_NOIDLE這個(gè)service tree。
每一個(gè)service tree都對應了若干個(gè)cfq_queue隊列，每個(gè)cfq_queue隊列對應一個(gè)進(jìn)程，這個(gè)我們后續再詳細說(shuō)明。
cfq_group還維護了一個(gè)在cgroup內部所有進(jìn)程公用的異步IO請求隊列，其結構如下：
struct cfq_queue *async_cfqq[2][IOPRIO_BE_NR];
struct cfq_queue *async_idle_cfqq;
異步請求也分成了RT、BE、IDLE這三類(lèi)進(jìn)行處理，每一類(lèi)對應一個(gè)cfq_queue進(jìn)行排隊。BE和RT也實(shí)現了優(yōu)先級的支持，每一個(gè)類(lèi)型有IOPRIO_BE_NR這么多個(gè)優(yōu)先級，這個(gè)值定義為8，數組下標為0-7。我們目前分析的內核代碼版本為L(cháng)inux 4.4，可以看出，從cfq的角度來(lái)說(shuō)，已經(jīng)可以實(shí)現異步IO的cgroup支持了，我們需要定義一下這里所謂異步IO的含義，它僅僅表示從內存的buffer/cache中的數據同步到硬盤(pán)的IO請求，而不是aio(man 7 aio)或者linux的native異步io以及l(fā)ibaio機制，實(shí)際上這些所謂的“異步”IO機制，在內核中都是同步實(shí)現的(本質(zhì)上馮諾伊曼計算機沒(méi)有真正的“異步”機制)。
我們在上面已經(jīng)說(shuō)明過(guò)，由于進(jìn)程正常情況下都是將數據先寫(xiě)入buffer/cache，所以這種異步IO都是統一由cfq_group中的async請求隊列處理的。那么為什么在上面的service_tree中還要實(shí)現和一個(gè)ASYNC的類(lèi)型呢?這當然是為了支持區分進(jìn)程的異步IO并使之可以“完全公平”做準備嘍。實(shí)際上在最新的cgroup v2的blkio體系中，內核已經(jīng)支持了針對buffer IO的cgroup限速支持，而以上這些可能容易混淆的一堆類(lèi)型，都是在新的體系下需要用到的類(lèi)型標記。新體系的復雜度更高了，功能也更加強大，但是大家先不要著(zhù)急，正式的cgroup v2體系，在Linux 4.5發(fā)布的時(shí)候會(huì )正式跟大家見(jiàn)面。
我們繼續選擇service_tree的過(guò)程，三種優(yōu)先級類(lèi)型的service_tree的選擇就是根據類(lèi)型的優(yōu)先級來(lái)做選擇的，RT優(yōu)先級最高，BE其次，IDLE最低。就是說(shuō)，RT里有，就會(huì )一直處理RT，RT沒(méi)了再處理BE。每個(gè)service_tree對應一個(gè)元素為cfq_queue排隊的紅黑樹(shù)，而每個(gè)cfq_queue就是內核為進(jìn)程(線(xiàn)程)創(chuàng )建的請求隊列。每一個(gè)cfq_queue都會(huì )維護一個(gè)rb_key的變量，這個(gè)變量實(shí)際上就是這個(gè)隊列的IO服務(wù)時(shí)間(service time)。這里還是通過(guò)紅黑樹(shù)找到service time時(shí)間最短的那個(gè)cfq_queue進(jìn)行服務(wù)，以保證“完全公平”。
選擇好了cfq_queue之后，就要開(kāi)始處理這個(gè)隊列里的IO請求了。這里的調度方式基本跟deadline類(lèi)似。cfq_queue會(huì )對進(jìn)入隊列的每一個(gè)請求進(jìn)行兩次入隊，一個(gè)放進(jìn)fifo中，另一個(gè)放進(jìn)按訪(fǎng)問(wèn)扇區順序作為key的紅黑樹(shù)中。默認從紅黑樹(shù)中取請求進(jìn)行處理，當請求的延時(shí)時(shí)間達到deadline時(shí)，就從紅黑樹(shù)中取等待時(shí)間最長(cháng)的進(jìn)行處理，以保證請求不被餓死。
這就是整個(gè)cfq的調度流程，當然其中還有很多細枝末節沒(méi)有交代，比如合并處理以及順序處理等等。
CFQ的參數調整
理解整個(gè)調度流程有助于我們決策如何調整cfq的相關(guān)參數。所有cfq的可調參數都可以在/sys/class/block/sda/queue/iosched/目錄下找到，當然，在你的系統上，請將sda替換為相應的磁盤(pán)名稱(chēng)。我們來(lái)看一下都有什么：
[root@zorrozou-pc0 zorro]# echo cfq > /sys/block/sda/queue/scheduler
[root@zorrozou-pc0 zorro]# ls /sys/class/block/sda/queue/iosched/
back_seek_max back_seek_penalty fifo_expire_async fifo_expire_sync group_idle low_latency quantum slice_async slice_async_rq slice_idle slice_sync target_latency
這些參數部分是跟機械硬盤(pán)磁頭尋道方式有關(guān)的，如果其說(shuō)明你看不懂，請先補充相關(guān)知識：
back_seek_max:磁頭可以向后尋址的最大范圍，默認值為16M。
back_seek_penalty:向后尋址的懲罰系數。這個(gè)值是跟向前尋址進(jìn)行比較的。
以上兩個(gè)是為了防止磁頭尋道發(fā)生抖動(dòng)而導致尋址過(guò)慢而設置的�；舅悸肥沁@樣，一個(gè)io請求到來(lái)的時(shí)候，cfq會(huì )根據其尋址位置預估一下其磁頭尋道成本。首先設置一個(gè)最大值back_seek_max，對于請求所訪(fǎng)問(wèn)的扇區號在磁頭后方的請求，只要尋址范圍沒(méi)有超過(guò)這個(gè)值，cfq會(huì )像向前尋址的請求一樣處理它。然后再設置一個(gè)評估成本的系數back_seek_penalty，相對于磁頭向前尋址，向后尋址的距離為1/2(1/back_seek_penalty)時(shí)，cfq認為這兩個(gè)請求尋址的代價(jià)是相同。這兩個(gè)參數實(shí)際上是cfq判斷請求合并處理的條件限制，凡事復合這個(gè)條件的請求，都會(huì )盡量在本次請求處理的時(shí)候一起合并處理。
fifo_expire_async:設置異步請求的超時(shí)時(shí)間。同步請求和異步請求是區分不同隊列處理的，cfq在調度的時(shí)候一般情況都會(huì )優(yōu)先處理同步請求，之后再處理異步請求，除非異步請求符合上述合并處理的條件限制范圍內。當本進(jìn)程的隊列被調度時(shí)，cfq會(huì )優(yōu)先檢查是否有異步請求超時(shí)，就是超過(guò)fifo_expire_async參數的限制。如果有，則優(yōu)先發(fā)送一個(gè)超時(shí)的請求，其余請求仍然按照優(yōu)先級以及扇區編號大小來(lái)處理。
fifo_expire_sync:這個(gè)參數跟上面的類(lèi)似，區別是用來(lái)設置同步請求的超時(shí)時(shí)間。
slice_idle:參數設置了一個(gè)等待時(shí)間。這讓cfq在切換cfq_queue或service tree的時(shí)候等待一段時(shí)間，目的是提高機械硬盤(pán)的吞吐量。一般情況下，來(lái)自同一個(gè)cfq_queue或者service tree的IO請求的尋址局部性更好，所以這樣可以減少磁盤(pán)的尋址次數。這個(gè)值在機械硬盤(pán)上默認為非零。當然在固態(tài)硬盤(pán)或者硬RAID設備上設置這個(gè)值為非零會(huì )降低存儲的效率，因為固態(tài)硬盤(pán)沒(méi)有磁頭尋址這個(gè)概念，所以在這樣的設備上應該設置為0，關(guān)閉此功能。
group_idle:這個(gè)參數也跟上一個(gè)參數類(lèi)似，區別是當cfq要切換cfq_group的時(shí)候會(huì )等待一段時(shí)間。在cgroup的場(chǎng)景下，如果我們沿用slice_idle的方式，那么空轉等待可能會(huì )在cgroup組內每個(gè)進(jìn)程的cfq_queue切換時(shí)發(fā)生。這樣會(huì )如果這個(gè)進(jìn)程一直有請求要處理的話(huà)，那么直到這個(gè)cgroup的配額被耗盡，同組中的其它進(jìn)程也可能無(wú)法被調度到。這樣會(huì )導致同組中的其它進(jìn)程餓死而產(chǎn)生IO性能瓶頸。在這種情況下，我們可以將slice_idle = 0而group_idle = 8。這樣空轉等待就是以cgroup為單位進(jìn)行的，而不是以cfq_queue的進(jìn)程為單位進(jìn)行，以防止上述問(wèn)題產(chǎn)生。
low_latency:這個(gè)是用來(lái)開(kāi)啟或關(guān)閉cfq的低延時(shí)(low latency)模式的開(kāi)關(guān)。當這個(gè)開(kāi)關(guān)打開(kāi)時(shí)，cfq將會(huì )根據target_latency的參數設置來(lái)對每一個(gè)進(jìn)程的分片時(shí)間(slice time)進(jìn)行重新計算。這將有利于對吞吐量的公平(默認是對時(shí)間片分配的公平)。關(guān)閉這個(gè)參數(設置為0)將忽略target_latency的值。這將使系統中的進(jìn)程完全按照時(shí)間片方式進(jìn)行IO資源分配。這個(gè)開(kāi)關(guān)默認是打開(kāi)的。
我們已經(jīng)知道cfq設計上有“空轉”(idling)這個(gè)概念，目的是為了可以讓連續的讀寫(xiě)操作盡可能多的合并處理，減少磁頭的尋址操作以便增大吞吐量。如果有進(jìn)程總是很快的進(jìn)行順序讀寫(xiě)，那么它將因為cfq的空轉等待命中率很高而導致其它需要處理IO的進(jìn)程響應速度下降，如果另一個(gè)需要調度的進(jìn)程不會(huì )發(fā)出大量順序IO行為的話(huà)，系統中不同進(jìn)程IO吞吐量的表現就會(huì )很不均衡。就比如，系統內存的cache中有很多臟頁(yè)要寫(xiě)回時(shí)，桌面又要打開(kāi)一個(gè)瀏覽器進(jìn)行操作，這時(shí)臟頁(yè)寫(xiě)回的后臺行為就很可能會(huì )大量命中空轉時(shí)間，而導致瀏覽器的小量IO一直等待，讓用戶(hù)感覺(jué)瀏覽器運行響應速度變慢。這個(gè)low_latency主要是對這種情況進(jìn)行優(yōu)化的選項，當其打開(kāi)時(shí)，系統會(huì )根據target_latency的配置對因為命中空轉而大量占用IO吞吐量的進(jìn)程進(jìn)行限制，以達到不同進(jìn)程IO占用的吞吐量的相對均衡。這個(gè)開(kāi)關(guān)比較合適在類(lèi)似桌面應用的場(chǎng)景下打開(kāi)。
target_latency:當low_latency的值為開(kāi)啟狀態(tài)時(shí)，cfq將根據這個(gè)值重新計算每個(gè)進(jìn)程分配的IO時(shí)間片長(cháng)度。
quantum:這個(gè)參數用來(lái)設置每次從cfq_queue中處理多少個(gè)IO請求。在一個(gè)隊列處理事件周期中，超過(guò)這個(gè)數字的IO請求將不會(huì )被處理。這個(gè)參數只對同步的請求有效。
slice_sync:當一個(gè)cfq_queue隊列被調度處理時(shí)，它可以被分配的處理總時(shí)間是通過(guò)這個(gè)值來(lái)作為一個(gè)計算參數指定的。公式為：time_slice = slice_sync + (slice_sync/5 * (4 – prio))。這個(gè)參數對同步請求有效。
slice_async:這個(gè)值跟上一個(gè)類(lèi)似，區別是對異步請求有效。
slice_async_rq:這個(gè)參數用來(lái)限制在一個(gè)slice的時(shí)間范圍內，一個(gè)隊列最多可以處理的異步請求個(gè)數。請求被處理的最大個(gè)數還跟相關(guān)進(jìn)程被設置的io優(yōu)先級有關(guān)。
【Linux系統基礎知識：IO調度】相關(guān)文章：
Linux認證基礎知識：linux操作系統目錄結構03-08
Linux操作系統文件系統基礎知識03-07
linux文件系統基礎知識匯總03-09
Java入門(mén)基礎知識：Java IO（輸入/輸出）03-07
Linux系統下ftp的管理03-05
Linux操作系統概述03-06
Linux文件系統簡(jiǎn)介02-27