Linux的IO排程

   IO排程發生在Linux核心的IO排程層。這個層次是針對Linux的整體IO層次體系來說的。從read()或者write()系統調用的角度來說，Linux整體IO體系可以分為七層，它們分别是：

VFS層：虛拟檔案系統層。由于核心要跟多種檔案系統打交道，而每一種檔案系統所實作的資料結構和相關方法都可能不盡相同，是以，核心抽象了這一層，專門用來适配各種檔案系統，并對外提供統一操作接口。

檔案系統層：不同的檔案系統實作自己的操作過程，提供自己特有的特征，具體不多說了，大家願意的話自己去看代碼即可。

頁緩存層：負責真對page的緩存。

通用塊層：由于絕大多數情況的io操作是跟塊裝置打交道，是以Linux在此提供了一個類似vfs層的塊裝置操作抽象層。下層對接各種不同屬性的塊裝置，對上提供統一的Block IO請求标準。

IO排程層：因為絕大多數的塊裝置都是類似磁盤這樣的裝置，是以有必要根據這類裝置的特點以及應用的不同特點來設定一些不同的排程算法和隊列。以便在不同的應用環境下有針對性的提高磁盤的讀寫效率，這裡就是大名鼎鼎的Linux電梯所起作用的地方。針對機械硬碟的各種排程方法就是在這實作的。

塊裝置驅動層：驅動層對外提供相對比較進階的裝置操作接口，往往是C語言的，而下層對接裝置本身的操作方法和規範。

塊裝置層：這層就是具體的實體裝置了，定義了各種真對裝置操作方法和規範。

我們今天要研究的内容主要在IO排程這一層。它要解決的核心問題是，如何提高塊裝置IO的整體性能？這一層也主要是針對機械硬碟結構而設計的。衆所周知，機械硬碟的存儲媒體是磁盤，磁頭在盤片上移動進行磁道尋址，行為類似播放一張唱片。這種結構的特點是，順序通路時吞吐量較高，但是如果一旦對盤片有随機通路，那麼大量的時間都會浪費在磁頭的移動上，這時候就會導緻每次IO的響應時間變長，極大的降低IO的響應速度。磁頭在盤片上尋道的操作，類似電梯排程，如果在尋道的過程中，能把順序路過的相關磁道的資料請求都“順便”處理掉，那麼就可以在比較小影響響應速度的前提下，提高整體IO的吞吐量。這就是我們問什麼要設計IO排程算法的原因。在最開始的時期，Linux把這個算法命名為Linux電梯算法。目前在核心中預設開啟了三種算法，其實嚴格算應該是兩種，因為第一種叫做noop，就是空操作排程算法，也就是沒有任何排程操作，并不對io請求進行排序，僅僅做适當的io合并的一個fifo隊列。

目前核心中預設的排程算法應該是cfq，叫做完全公平隊列排程。這個排程算法人如其名，它試圖給所有程序提供一個完全公平的IO操作環境。它為每個程序建立一個同步IO排程隊列，并預設以時間片和請求數限定的方式配置設定IO資源，以此保證每個程序的IO資源占用是公平的，cfq還實作了針對程序級别的優先級排程，這個我們後面會詳細解釋。

檢視和修改IO排程算法的方法是：

cfq是通用伺服器比較好的IO排程算法選擇，對桌面使用者也是比較好的選擇。但是對于很多IO壓力較大的場景就并不是很适應，尤其是IO壓力集中在某些程序上的場景。因為這種場景我們需要更多的滿足某個或者某幾個程序的IO響應速度，而不是讓所有的程序公平的使用IO，比如資料庫應用。

deadline排程（最終期限排程）就是更适合上述場景的解決方案。deadline實作了四個隊列，其中兩個分别處理正常read和write，按扇區号排序，進行正常io的合并處理以提高吞吐量.因為IO請求可能會集中在某些磁盤位置，這樣會導緻新來的請求一直被合并，可能會有其他磁盤位置的io請求被餓死。是以實作了另外兩個處理逾時read和write的隊列，按請求建立時間排序，如果有逾時的請求出現，就放進這兩個隊列，排程算法保證逾時（達到最終期限時間）的隊列中的請求會優先被處理，防止請求被餓死。

不久前，核心還是預設标配四種算法，還有一種叫做as的算法（Anticipatory scheduler），預測排程算法。一個高大上的名字，搞得我一度認為Linux核心都會算命了。結果發現，無非是在基于deadline算法做io排程的之前等一小會時間，如果這段時間内有可以合并的io請求到來，就可以合并處理，提高deadline排程的在順序讀寫情況下的資料吞吐量。其實這根本不是啥預測，我覺得不如叫撞大運排程算法，當然這種政策在某些特定場景差效果不錯。但是在大多數場景下，這個排程不僅沒有提高吞吐量，還降低了響應速度，是以核心幹脆把它從預設配置裡删除了。畢竟Linux的宗旨是實用，而我們也就不再這個排程算法上多費口舌了。

CFQ是核心預設選擇的IO排程隊列，它在桌面應用場景以及大多數常見應用場景下都是很好的選擇。如何實作一個所謂的完全公平隊列（Completely Fair Queueing）？首先我們要了解所謂的公平是對誰的公平？從作業系統的角度來說，産生操作行為的主體都是程序，是以這裡的公平是針對每個程序而言的，我們要試圖讓程序可以公平的占用IO資源。那麼如何讓程序公平的占用IO資源？我們需要先了解什麼是IO資源。當我們衡量一個IO資源的時候，一般喜歡用的是兩個機關，一個是資料讀寫的帶寬，另一個是資料讀寫的IOPS。帶寬就是以時間為機關的讀寫資料量，比如，100Mbyte/s。而IOPS是以時間為機關的讀寫次數。在不同的讀寫情境下，這兩個機關的表現可能不一樣，但是可以确定的是，兩個機關的任何一個達到了性能上限，都會成為IO的瓶頸。從機械硬碟的結構考慮，如果讀寫是順序讀寫，那麼IO的表現是可以通過比較少的IOPS達到較大的帶寬，因為可以合并很多IO，也可以通過預讀等方式加速資料讀取效率。當IO的表現是偏向于随機讀寫的時候，那麼IOPS就會變得更大，IO的請求的合并可能性下降，當每次io請求資料越少的時候，帶寬表現就會越低。從這裡我們可以了解，針對程序的IO資源的主要表現形式有兩個，程序在機關時間内送出的IO請求個數和程序占用IO的帶寬。其實無論哪個，都是跟程序配置設定的IO處理時間長度緊密相關的。

有時業務可以在較少IOPS的情況下占用較大帶寬，另外一些則可能在較大IOPS的情況下占用較少帶寬，是以對程序占用IO的時間進行排程才是相對最公平的。即，我不管你是IOPS高還是帶寬占用高，到了時間咱就換下一個程序處理，你愛咋樣咋樣。是以，cfq就是試圖給所有程序配置設定等同的塊裝置使用的時間片，程序在時間片内，可以将産生的IO請求送出給塊裝置進行處理，時間片結束，程序的請求将排進它自己的隊列，等待下次排程的時候進行處理。這就是cfq的基本原理。

當然，現實生活中不可能有真正的“公平”，常見的應用場景下，我們很肯能需要人為的對程序的IO占用進行人為指定優先級，這就像對程序的CPU占用設定優先級的概念一樣。是以，除了針對時間片進行公平隊列排程外，cfq還提供了優先級支援。每個程序都可以設定一個IO優先級，cfq會根據這個優先級的設定情況作為排程時的重要參考因素。優先級首先分成三大類：RT、BE、IDLE，它們分别是實時（Real Time）、最佳效果（Best Try）和閑置（Idle）三個類别，對每個類别的IO，cfq都使用不同的政策進行處理。另外，RT和BE類别中，分别又再劃分了8個子優先級實作更細節的QOS需求，而IDLE隻有一個子優先級。

另外，我們都知道核心預設對存儲的讀寫都是經過緩存（buffer/cache）的，在這種情況下，cfq是無法區分目前處理的請求是來自哪一個程序的。隻有在程序使用同步方式（sync read或者sync wirte）或者直接IO（Direct IO）方式進行讀寫的時候，cfq才能區分出IO請求來自哪個程序。是以，除了針對每個程序實作的IO隊列以外，還實作了一個公共的隊列用來處理異步請求。

在此，我們對整體資料結構做一個簡要描述：首先，cfq通過一個叫做cfq_data的資料結構維護了整個排程器流程。在一個支援了cgroup功能的cfq中，全部程序被分成了若幹個contral group進行管理。每個cgroup在cfq中都有一個cfq_group的結構進行描述，所有的cgroup都被作為一個排程對象放進一個紅黑樹中，并以vdisktime為key進行排序。vdisktime這個時間紀錄的是目前cgroup所占用的io時間，每次對cgroup進行排程時，總是通過紅黑樹選擇目前vdisktime時間最少的cgroup進行處理，以保證所有cgroups之間的IO資源占用“公平”。當然我們知道，cgroup是可以對blkio進行資源比例配置設定的，其作用原理就是，配置設定比例大的cgroup占用vdisktime時間增長較慢，配置設定比例小的vdisktime時間增長較快，快慢與配置設定比例成正比。這樣就做到了不同的cgroup配置設定的IO比例不一樣，并且在cfq的角度看來依然是“公平“的。

選擇好了需要處理的cgroup（cfq_group）之後，排程器需要決策選擇下一步的service_tree。service_tree這個資料結構對應的都是一系列的紅黑樹，主要目的是用來實作請求優先級分類的，就是RT、BE、IDLE的分類。每一個cfq_group都維護了7個service_trees，其定義如下：

其中service_tree_idle就是用來給IDLE類型的請求進行排隊用的紅黑樹。而上面二維數組，首先第一個次元針對RT和BE分别各實作了一個數組，每一個數組中都維護了三個紅黑樹，分别對應三種不同子類型的請求，分别是：SYNC、SYNC_NOIDLE以及ASYNC。我們可以認為SYNC相當于SYNC_IDLE并與SYNC_NOIDLE對應。idling是cfq在設計上為了盡量合并連續的IO請求以達到提高吞吐量的目的而加入的機制，我們可以了解為是一種“空轉”等待機制。空轉是指，當一個隊列處理一個請求結束後，會在發生排程之前空等一小會時間，如果下一個請求到來，則可以減少磁頭尋址，繼續處理順序的IO請求。為了實作這個功能，cfq在service_tree這層資料結構這實作了SYNC隊列，如果請求是同步順序請求，就入隊這個service tree，如果請求是同步随機請求，則入隊SYNC_NOIDLE隊列，以判斷下一個請求是否是順序請求。所有的異步寫操作請求将入隊ASYNC的service tree，并且針對這個隊列沒有空轉等待機制。此外，cfq還對SSD這樣的硬碟有特殊調整，當cfq發現儲存設備是一個ssd硬碟這樣的隊列深度更大的裝置時，所有針對單獨隊列的空轉都将不生效，所有的IO請求都将入隊SYNC_NOIDLE這個service tree。

每一個service tree都對應了若幹個cfq_queue隊列，每個cfq_queue隊列對應一個程序，這個我們後續再詳細說明。

cfq_group還維護了一個在cgroup内部所有程序公用的異步IO請求隊列，其結構如下：

異步請求也分成了RT、BE、IDLE這三類進行處理，每一類對應一個cfq_queue進行排隊。BE和RT也實作了優先級的支援，每一個類型有IOPRIO_BE_NR這麼多個優先級，這個值定義為8，數組下标為0-7。我們目前分析的核心代碼版本為Linux 4.4，可以看出，從cfq的角度來說，已經可以實作異步IO的cgroup支援了，我們需要定義一下這裡所謂異步IO的含義，它僅僅表示從記憶體的buffer/cache中的資料同步到硬碟的IO請求，而不是aio(man 7 aio)或者linux的native異步io以及libaio機制，實際上這些所謂的“異步”IO機制，在核心中都是同步實作的（本質上馮諾伊曼計算機沒有真正的“異步”機制）。

我們在上面已經說明過，由于程序正常情況下都是将資料先寫入buffer/cache，是以這種異步IO都是統一由cfq_group中的async請求隊列處理的。那麼為什麼在上面的service_tree中還要實作和一個ASYNC的類型呢？這當然是為了支援區分程序的異步IO并使之可以“完全公平”做準備喽。實際上在最新的cgroup v2的blkio體系中，核心已經支援了針對buffer IO的cgroup限速支援，而以上這些可能容易混淆的一堆類型，都是在新的體系下需要用到的類型标記。新體系的複雜度更高了，功能也更加強大，但是大家先不要着急，正式的cgroup v2體系，在Linux 4.5釋出的時候會正式跟大家見面。

我們繼續選擇service_tree的過程，三種優先級類型的service_tree的選擇就是根據類型的優先級來做選擇的，RT優先級最高，BE其次，IDLE最低。就是說，RT裡有，就會一直處理RT，RT沒了再處理BE。每個service_tree對應一個元素為cfq_queue排隊的紅黑樹，而每個cfq_queue就是核心為程序（線程）建立的請求隊列。每一個cfq_queue都會維護一個rb_key的變量，這個變量實際上就是這個隊列的IO服務時間（service time）。這裡還是通過紅黑樹找到service time時間最短的那個cfq_queue進行服務，以保證“完全公平”。

選擇好了cfq_queue之後，就要開始處理這個隊列裡的IO請求了。這裡的排程方式基本跟deadline類似。cfq_queue會對進入隊列的每一個請求進行兩次入隊，一個放進fifo中，另一個放進按通路扇區順序作為key的紅黑樹中。預設從紅黑樹中取請求進行處理，當請求的延時時間達到deadline時，就從紅黑樹中取等待時間最長的進行處理，以保證請求不被餓死。

這就是整個cfq的排程流程，當然其中還有很多細枝末節沒有交代，比如合并處理以及順序處理等等。

了解整個排程流程有助于我們決策如何調整cfq的相關參數。所有cfq的可調參數都可以在/sys/class/block/sda/queue/iosched/目錄下找到，當然，在你的系統上，請将sda替換為相應的磁盤名稱。我們來看一下都有什麼：

這些參數部分是跟機械硬碟磁頭尋道方式有關的，如果其說明你看不懂，請先補充相關知識：

back_seek_max:磁頭可以向後尋址的最大範圍，預設值為16M。

back_seek_penalty:向後尋址的懲罰系數。這個值是跟向前尋址進行比較的。

以上兩個是為了防止磁頭尋道發生抖動而導緻尋址過慢而設定的。基本思路是這樣，一個io請求到來的時候，cfq會根據其尋址位置預估一下其磁頭尋道成本。首先設定一個最大值back_seek_max，對于請求所通路的扇區号在磁頭後方的請求，隻要尋址範圍沒有超過這個值，cfq會像向前尋址的請求一樣處理它。然後再設定一個評估成本的系數back_seek_penalty，相對于磁頭向前尋址，向後尋址的距離為1/2(1/back_seek_penalty)時，cfq認為這兩個請求尋址的代價是相同。這兩個參數實際上是cfq判斷請求合并處理的條件限制，凡事複合這個條件的請求，都會盡量在本次請求處理的時候一起合并處理。

fifo_expire_async:設定異步請求的逾時時間。同步請求和異步請求是區分不同隊列處理的，cfq在排程的時候一般情況都會優先處理同步請求，之後再處理異步請求，除非異步請求符合上述合并處理的條件限制範圍内。當本程序的隊列被排程時，cfq會優先檢查是否有異步請求逾時，就是超過fifo_expire_async參數的限制。如果有，則優先發送一個逾時的請求，其餘請求仍然按照優先級以及扇區編号大小來處理。

fifo_expire_sync:這個參數跟上面的類似，差別是用來設定同步請求的逾時時間。

slice_idle:參數設定了一個等待時間。這讓cfq在切換cfq_queue或service tree的時候等待一段時間，目的是提高機械硬碟的吞吐量。一般情況下，來自同一個cfq_queue或者service tree的IO請求的尋址局部性更好，是以這樣可以減少磁盤的尋址次數。這個值在機械硬碟上預設為非零。當然在固态硬碟或者硬RAID裝置上設定這個值為非零會降低存儲的效率，因為固态硬碟沒有磁頭尋址這個概念，是以在這樣的裝置上應該設定為0，關閉此功能。

group_idle:這個參數也跟上一個參數類似，差別是當cfq要切換cfq_group的時候會等待一段時間。在cgroup的場景下，如果我們沿用slice_idle的方式，那麼空轉等待可能會在cgroup組内每個程序的cfq_queue切換時發生。這樣會如果這個程序一直有請求要處理的話，那麼直到這個cgroup的配額被耗盡，同組中的其它程序也可能無法被排程到。這樣會導緻同組中的其它程序餓死而産生IO性能瓶頸。在這種情況下，我們可以将slice_idle ＝ 0而group_idle ＝ 8。這樣空轉等待就是以cgroup為機關進行的，而不是以cfq_queue的程序為機關進行，以防止上述問題産生。

low_latency:這個是用來開啟或關閉cfq的低延時（low latency）模式的開關。當這個開關打開時，cfq将會根據target_latency的參數設定來對每一個程序的分片時間（slice time）進行重新計算。這将有利于對吞吐量的公平（預設是對時間片配置設定的公平）。關閉這個參數（設定為0）将忽略target_latency的值。這将使系統中的程序完全按照時間片方式進行IO資源配置設定。這個開關預設是打開的。

我們已經知道cfq設計上有“空轉”（idling）這個概念，目的是為了可以讓連續的讀寫操作盡可能多的合并處理，減少磁頭的尋址操作以便增大吞吐量。如果有程序總是很快的進行順序讀寫，那麼它将因為cfq的空轉等待命中率很高而導緻其它需要處理IO的程序響應速度下降，如果另一個需要排程的程序不會發出大量順序IO行為的話，系統中不同程序IO吞吐量的表現就會很不均衡。就比如，系統記憶體的cache中有很多髒頁要寫回時，桌面又要打開一個浏覽器進行操作，這時髒頁寫回的背景行為就很可能會大量命中空轉時間，而導緻浏覽器的小量IO一直等待，讓使用者感覺浏覽器運作響應速度變慢。這個low_latency主要是對這種情況進行優化的選項，當其打開時，系統會根據target_latency的配置對因為命中空轉而大量占用IO吞吐量的程序進行限制，以達到不同程序IO占用的吞吐量的相對均衡。這個開關比較合适在類似桌面應用的場景下打開。

target_latency:當low_latency的值為開啟狀态時，cfq将根據這個值重新計算每個程序配置設定的IO時間片長度。

quantum:這個參數用來設定每次從cfq_queue中處理多少個IO請求。在一個隊列處理事件周期中，超過這個數字的IO請求将不會被處理。這個參數隻對同步的請求有效。

slice_sync:當一個cfq_queue隊列被排程處理時，它可以被配置設定的處理總時間是通過這個值來作為一個計算參數指定的。公式為：time_slice = slice_sync + (slice_sync/5 * (4 – prio))。這個參數對同步請求有效。

slice_async:這個值跟上一個類似，差別是對異步請求有效。

slice_async_rq:這個參數用來限制在一個slice的時間範圍内，一個隊列最多可以處理的異步請求個數。請求被處理的最大個數還跟相關程序被設定的io優先級有關。

我們已經知道，預設情況下cfq是以時間片方式支援的帶優先級的排程來保證IO資源占用的公平。高優先級的程序将得到更多的時間片長度，而低優先級的程序時間片相對較小。當我們的存儲是一個高速并且支援NCQ（原生指令隊列）的裝置的時候，我們最好可以讓其可以從多個cfq隊列中處理多路的請求，以便提升NCQ的使用率。此時使用時間片的配置設定方式配置設定資源就顯得不合時宜了，因為基于時間片的配置設定，同一時刻最多能處理的請求隊列隻有一個。這時，我們需要切換cfq的模式為IOPS模式。切換方式很簡單，就是将slice_idle=0即可。核心會自動檢測你的儲存設備是否支援NCQ，如果支援的話cfq會自動切換為IOPS模式。

另外，在預設的基于優先級的時間片方式下，我們可以使用ionice指令來調整程序的IO優先級。程序預設配置設定的IO優先級是根據程序的nice值計算而來的，計算方法可以在man ionice中看到，這裡不再廢話。

deadline排程算法相對cfq要簡單很多。其設計目标是，在保證請求按照裝置扇區的順序進行通路的同時，兼顧其它請求不被餓死，要在一個最終期限前被排程到。我們知道磁頭對磁盤的尋道是可以進行順序通路和随機通路的，因為尋道延時時間的關系，順序通路時IO的吞吐量更大，随機通路的吞吐量小。如果我們想為一個機械硬碟進行吞吐量優化的話，那麼就可以讓排程器按照盡量複合順序通路的IO請求進行排序，之後請求以這樣的順序發送給硬碟，就可以使IO的吞吐量更大。但是這樣做也有另一個問題，就是如果此時出現了一個請求，它要通路的磁道離目前磁頭所在磁道很遠，應用的請求又大量集中在目前磁道附近。導緻大量請求一直會被合并和插隊處理，而那個要通路比較遠磁道的請求将因為一直不能被排程而餓死。deadline就是這樣一種排程器，能在保證IO最大吞吐量的情況下，盡量使遠端請求在一個期限内被排程而不被餓死的排程器。

為了實作上述目标，deadline排程器實作了兩類隊列，一類負責對請求按照通路扇區進行排序。這個隊列使用紅黑樹組織，叫做sort_list。另一類對請求的通路時間進行排序。使用連結清單組織，叫做fifo_list。

由于讀寫請求的明顯處理差異，在每一類隊列中，又按請求的讀寫類型分别分了兩個隊列，就是說deadline排程器實際上有4個隊列：

按照扇區通路順序排序的讀隊列。

按照扇區通路順序排序的寫隊列。

按照請求時間排序的讀隊列。

按照請求時間排序的寫隊列。

deadline之是以要對讀寫隊列進行分離，是因為要實作讀操作比寫操作更高的優先級。從應用的角度來看，讀操作一般都是同步行為，就是說，讀的時候程式一般都要等到資料傳回後才能做下一步的處理。而寫操作的同步需求并不明顯，一般程式都可以将資料寫到緩存，之後由核心負責同步到存儲上即可。是以，對讀操作進行優化可以明顯的得到收益。當然，deadline在這樣的情況下必然要對寫操作會餓死的情況進行考慮，保證其不會被餓死。

deadline的入隊很簡單：當一個新的IO請求産生并進行了必要的合并操作之後，它在deadline排程器中會分别按照扇區順序和請求産生時間分别入隊sort_list和fifo_list。并再進一步根據請求的讀寫類型入隊到相應的讀或者寫隊列。

deadline的出隊處理相對麻煩一點：

首先判斷讀隊列是否為空，如果讀隊列不為空并且寫隊列沒發生饑餓（starved < writes_starved）則處理讀隊列，否則處理寫隊列（第4部）。

進入讀隊列處理後，首先檢查fifo_list中是否有超過最終期限（read_expire）的讀請求，如果有則處理該請求以防止被餓死。

如果上一步為假，則處理順序的讀請求以增大吞吐。

如果第1部檢查讀隊列為空或者寫隊列處于饑餓狀态，那麼應該處理寫隊列。其過程和讀隊列處理類似。

進入寫隊列處理後，首先檢查fifo_list中是否有超過最終期限（write_expire）的寫請求，如果有則處理該請求以防止被餓死。

如果上一步為假，則處理順序的寫請求以增大吞吐。

整個處理邏輯就是這樣，簡單總結其原則就是，讀的優先級高于寫，達到deadline時間的請求處理高于順序處理。正常情況下保證順序讀寫，保證吞吐量，有饑餓的情況下處理饑餓。

deadline的可調參數相對較少，包括：

read_expire:讀請求的逾時時間設定，機關為ms。當一個讀請求入隊deadline的時候，其過期時間将被設定為目前時間＋read_expire，并放倒fifo_list中進行排序。

write_expire:寫請求的逾時時間設定，機關為ms。功能根讀請求類似。

fifo_batch:在順序（sort_list）請求進行處理的時候，deadline将以batch為機關進行處理。每一個batch處理的請求個數為這個參數所限制的個數。在一個batch處理的過程中，不會産生是否逾時的檢查，也就不會産生額外的磁盤尋道時間。這個參數可以用來平衡順序處理和饑餓時間的沖突，當饑餓時間需要盡可能的符合預期的時候，我們可以調小這個值，以便盡可能多的檢查是否有饑餓産生并及時處理。增大這個值當然也會增大吞吐量，但是會導緻處理饑餓請求的延時變長。

writes_starved:這個值是在上述deadline出隊處理第一步時做檢查用的。用來判斷當讀隊列不為空時，寫隊列的饑餓程度是否足夠高，以時deadline放棄讀請求的處理而處理寫請求。當檢查存在有寫請求的時候，deadline并不會立即對寫請求進行處理，而是給相關資料結構中的starved進行累計，如果這是第一次檢查到有寫請求進行處理，那麼這個計數就為1。如果此時writes_starved值為2，則我們認為此時饑餓程度還不足夠高，是以繼續處理讀請求。隻有當starved >= writes_starved的時候，deadline才回去處理寫請求。可以認為這個值是用來平衡deadline對讀寫請求處理優先級狀态的，這個值越大，則寫請求越被滞後處理，越小，寫請求就越可以獲得趨近于讀請求的優先級。

front_merges:當一個新請求進入隊列的時候，如果其請求的扇區距離目前扇區很近，那麼它就是可以被合并處理的。而這個合并可能有兩種情況，一個是向目前位置後合并，另一種是向前合并。在某些場景下，向前合并是不必要的，那麼我們就可以通過這個參數關閉向前合并。預設deadline支援向前合并，設定為0關閉。

noop排程器是最簡單的排程器。它本質上就是一個連結清單實作的fifo隊列，并對請求進行簡單的合并處理。排程器本身并沒有提供任何可疑配置的參數。

根據以上幾種io排程算法的分析，我們應該能對各種排程算法的使用場景有一些大緻的思路了。從原理上看，cfq是一種比較通用的排程算法，它是一種以程序為出發點考慮的排程算法，保證大家盡量公平。deadline是一種以提高機械硬碟吞吐量為思考出發點的排程算法，盡量保證在有io請求達到最終期限的時候進行排程，非常适合業務比較單一并且IO壓力比較重的業務，比如資料庫。而noop呢？其實如果我們把我們的思考對象拓展到固态硬碟，那麼你就會發現，無論cfq還是deadline，都是針對機械硬碟的結構進行的隊列算法調整，而這種調整對于固态硬碟來說，完全沒有意義。對于固态硬碟來說，IO排程算法越複雜,額外要處理的邏輯就越多，效率就越低。是以，固态硬碟這種場景下使用noop是最好的，deadline次之，而cfq由于複雜度的原因，無疑效率最低。

轉載位址:http://liwei.life/2016/03/14/linux_io_scheduler/

      本文轉自027ryan  51CTO部落格，原文連結：http://blog.51cto.com/ucode/1751626，如需轉載請自行聯系原作者