小結一下linux 2 6核心的四種IO排程演算法

2021-08-31 05:13:59 字數 2407 閱讀 8645

在linux 2.6中,有四種關於io的排程演算法,下面綜合小結一下:

1) noop

noop演算法的全寫為no operation。該演算法實現了最最簡單的fifo佇列,所有io請求大致按照先來後到的順序進行操作。之所以說「大致」,原因是noop在fifo的基礎上還做了相鄰io請求的合併,並不是完完全全按照先進先出的規則滿足io請求。noop假定i/o請求由驅動程式或者裝置做了優化或者重排了順序(就像乙個智慧型控制器完成的工作那樣)。在有些san環境下,這個選擇可能是最好選擇。noop 對於 io 不那麼操心,對所有的 io請求都用 fifo 佇列形式處理,預設認為 io 不會存在效能問題。這也使得 cpu 也不用那麼操心。當然,對於複雜一點的應用型別,使用這個排程器,使用者自己就會非常操心。

2) deadline scheduler

deadline在cfq的基礎上,解決了io請求餓死的極端情況。除了cfq本身具有的io排序佇列之外,deadline額外分別為讀io和寫io提供了fifo佇列。讀fifo佇列的最大等待時間為500ms,寫fifo佇列的最大等待時間為5s。fifo佇列內的io請求優先順序要比cfq佇列中的高,,而讀fifo佇列的優先順序又比寫fifo佇列的優先順序高。優先順序可以表示如下:

fifo(read) > fifo(write) > cfq

deadline 演算法保證對於既定的 io 請求以最小的延遲時間,從這一點理解,對於 dss 應用應該會是很適合的。

3) anticipatory scheduler

cfq和deadline考慮的焦點在於滿足零散io請求上。對於連續的io請求,比如順序讀,並沒有做優化。為了滿足隨機io和順序io混合的場景,linux還支援anticipatory排程演算法。anticipatory的在deadline的基礎上,為每個讀io都設定了6ms

的等待時間視窗。如果在這6ms內os收到了相鄰位置的讀io請求,就可以立即滿足

anticipatory scheduler(as) 曾經一度是 linux 2.6 kernel 的 io scheduler 。anticipatory 的中文含義是」預料的, 預想的」, 這個詞的確揭示了這個演算法的特點,簡單的說,有個 io 發生的時候,如果又有程序請求 io 操作,則將產生乙個預設的 6 毫秒猜測時間,猜測下乙個 程序請求 io 是要幹什麼的。這對於隨即讀取會造成比較大的延時,對資料庫應用很糟糕,而對於 web server 等則會表現的不錯。這個演算法也可以簡單理解為面向低速磁碟的,因為那個」猜測」實際上的目的是為了減少磁頭移動時間。

4)cfq

cfq演算法的全寫為completely fair queuing。該演算法的特點是按照io請求的位址進行排序,而不是按照先來後到的順序來進行響應。

在傳統的sas盤上,磁碟尋道花去了絕大多數的io響應時間。cfq的出發點是對io位址進行排序,以盡量少的磁碟旋轉次數來滿足盡可能多的io請求。在cfq演算法下,sas盤的吞吐量大大提高了。但是相比於noop的缺點是,先來的io請求並不一定能被滿足,可能會出現餓死的情況。

completely fair queuing (cfq, 完全公平佇列) 在 2.6.18 取代了 anticipatory scheduler 成為 linux kernel 預設的 io scheduler 。cfq 對每個程序維護乙個 io 佇列,各個程序發來的 io 請求會被 cfq 以輪循方式處理。也就是對每乙個 io 請求都是公平的。這使得 cfq 很適合離散讀的應用(eg: oltp db)。我所知道的企業級 linux 發行版中,suse linux 好像是最先預設用 cfq 的.

檢視和修改io排程器的演算法非常簡單。假設我們要對sda進行操作,如下所示:

cat /sys/block/sda/queue/scheduler

echo 「cfq」 > /sys/block/sda/queue/scheduler

總結:1 cfq和deadline考慮的焦點在於滿足零散io請求上。對於連續的io請求,比如順序讀,並沒有做優化。為了滿足隨機io和順序io混合的場景,linux還支援anticipatory排程演算法。anticipatory的在deadline的基礎上,為每個讀io都設定了6ms的等待時間視窗。如果在這6ms內os收到了相鄰位置的讀io請求,就可以立即滿足。

io排程器演算法的選擇,既取決於硬體特徵,也取決於應用場景。

在傳統的sas盤上,cfq、deadline、anticipatory都是不錯的選擇;對於專屬的資料庫伺服器,deadline的吞吐量和響應時間都表現良好。然而在新興的固態硬碟比如ssd、fusion io上,最簡單的noop反而可能是最好的演算法,因為其他三個演算法的優化是基於縮短尋道時間的,而固態硬碟沒有所謂的尋道時間且io響應時間非常短。

2 對於資料庫應用, anticipatory scheduler 的表現是最差的。deadline 在 dss 環境表現比 cfq 更好一點,而 cfq 綜合來看表現更好一些。這也難怪 rhel 4 預設的 io 排程器設定為 cfq. 而 rhel 4 比 rhel 3,整體 io 改進還是不小的。

linux2 6核心模組的編譯

首先將下面的程式寫進乙個hello1.c的檔案裡 vim hello1.c include linux module.h include linux kernel.h include linux init.h static int init lkp init void static void exi...

Linux2 6核心實現的是NPTL

nptl是乙個1 1的執行緒模型,即乙個執行緒對於乙個作業系統的排程程序,優點是非常簡單。而其他一些作業系統比如solaris則是mxn的,m對應建立的執行緒數,n對應作業系統可以執行的實體。n轉 全選 937 struct task struct pid,從字面上是process id,但其實是t...

Linux2 6 核心的 Initrd 機制解析

1 什麼是 initrd initrd 的英文含義是 boot loader initialized ram disk,就是由 boot loader 初始化的記憶體盤。在 linux核心啟動前,boot loader 會將儲存介質中的 initrd 檔案載入到記憶體,核心啟動時會在訪問真正的根檔案...