661
阿裏內核月報：2017年05月
1. A report from Netconf: Day 1
本文是2017年4月3日Netconf會議報告。主要的議題是：移除ndo_select_queue()函數，對於refcount_t類型引入開關，TC重定向導致內核陷入循環等。
移除ndo_select_queue()
ndo_select_queue()函數是大家首先討論的，它被用來決定往網絡接口發送數據包的時間和方式。主要的爭議是把它放在驅動裏麵是否合適，Alexander Duyck說Intel在考慮用ndo_select_queue()來說收/發包隊列的matching，不過目前也沒真正在用。
無線方麵倒是重度使用該函數，不過是用來做traffic分流，比如讓語音數據避開一個best-effort服務的擁擠隊列。不過該函數也不是做這個事情的唯一選擇，在無線協議棧裏麵基於fq_codel的流控機製也很有效。
接下來的問題就是怎麼把它移除了，很快我們就不會看到一個通用的ndo_select_queue()接口了。以後這個某個具體協議棧或者某個具體驅動操心的事情了。
refcount_t類型
refcount_t類型是kernel內部用來防止對象引用計數向上或者向下溢出的數據類型。大家的觀點是這樣的數據類型用於調試是可行的，但是不能默認enable，大家非常確信這樣的數據類型對網絡性能會有非常嚴重的影響，不過目前沒有數據來說明。
第二天關於KASan內存問題檢測的討論中，Eric也表達了類似refcount_t類型的觀點。這種檢測方法對一大批問題無能為力，還可能導致協議棧突破10%內存使用限製，因此有人建議檢測方法的開啟關閉應該用可選擇參數控製。用於debug特定問題是OK的，但是一直開啟就影響到網絡性能。
關於可選擇參數大家通常都會默認關閉，以至於這種檢測方法實際不會發揮作用因為不會測試到選擇參數控製的路徑。Eric解釋了一通Google的測試，最後也承認某些路徑確實無法完全顧及到。
最後總結一下的話，就是謹慎的小夥伴會更喜歡這種提高內核可靠性的方法，不過搞網絡的朋友因為性能方麵的考慮不能完全接受。
輕量級檢測/管理方法
Berg提出有時候用戶需要高性能獲取關心數據的方法，特別是無線應用裏麵。雖然已經有相關的機製但是開銷實在太大。Miller認為eBPF幹這個很合適。
VLAN 0的語義非一致性問題
Hannes Frederic Sowa在會上提了個無傷大雅的問題，即內核如何處理VLAN 0？理論上，VLAN 0表示沒有VLAN。但是內核現在處理VLAN 0的方式取決於VLAN模塊是否加載，以及VLAN 0接口是否創建。因此，有時數據包中的VLAN 0標記被直接丟棄，有時又沒有，出現語義不一致。追溯源頭，VLAN 0語義的破壞是由一個patch意外導致，Sowa計劃將恢複VLAN 0的原始語義。
循環之殤
內核TC (traffic-control)子係統的維護者Jamal Hadi Salim指出，利用tc REDIRECT特性能夠使內核陷入無限循環。隻要將REDIRECT的目的接口配置成源接口，就能很快重現這個問題。當然啦，隻要簡單的丟棄源接口和目的接口相同的數據包就可避免這種情況。更嚴重的是，當一個數據包從eth0發送到eth1, eth1又迅速的將這個包重定向到eth0。很明顯，隻有root用戶才有權限去刻意製造這種問題場景，管理員的錯，那又怪得了誰呢？
然而，當考慮到物理機上部署了容器的情況，事情就變得不那麼簡單了。一個非授信用戶可能在容器內部擁有root權限，並刻意構造這種問題場景，將會對運行在該服務器上的其它容器構成DoS攻擊。在特定條件下，還會導致內核死鎖。
Salim 發現，之所以會出現這個問題，是因為skb struct中用於標記數據包的兩個bits被砍掉了。這兩個bit是一種簡單的TTL機製，在每次循環中+1，當達到允許的最大限製時數據包被丟棄。正是這小小的TTL避免了死循環的出現。
當前的大趨勢是要精簡skb struct，至於是將這兩個bit重新召回，還是繼續忍受DoS威脅，期待後續發展。
Dump大數據
在一些場景下，用戶需要從內核中導出大量數據。Salim提供了一個真實的tc讀取6M entries的案例。但是，當前的基於netlink機製的API一次隻能讀取20 entries，效率超級低。Salim寫了個patch，提高一次讀數據的最大值到 8 x NLMSG_GOOD_SIZE.使性能提高一個數量級。顯然，這隻是一個臨時方案，社區還在尋找一個更通用完美的方案：從內核讀取大量統計信息的機製，允許在讀取過程中，數據仍然在不斷變化。
2. A report from Netconf: Day 2
本文是2017年4月4日Netconf會議報告的第二部分。主要的議題是VRF上套接字的綁定，eBPF程序的標識，IPv4/IPv6協議間的區別，數據中心硬件的變遷等等。
如何在VRF上綁定特定的socket
David Ahern帶來的第一個問題是關於如何將套接字綁定到一個指定的接口上。當前有如下四種方法可以完成這項工作：
- 使用SO_BINDTODEVICE選項
- 使用IP_PKTINFO選項
- 使用3.3版本內核引入的IP_UNICAST_IF標記
- 使用IPv6範圍ID前綴
這裏存在的問題是有太多方式可以完成綁定套接字到指定接口這一工作，而對這些方法的修改勢必會破壞ABI兼容。同時這些方法之間也存在著衝突。比如一個用戶使用了某種方法設置了一個標記，但是這一方式會破壞其他用戶已經完成的工作，同時這一問題內核並不會向用戶態進行匯報。參加會議的開發者同意需要添加一個衝突通知機製來通知用戶這一問題。
接下來Ahern提出了另一個問題，如何將套接字綁定到指定的VRF上。比如一個UDP組播套接字如何綁定到VRF上。
Tom Herbert說此前曾經討論過通過擴展bind(2)係統調用的方式來解決這一問題。即通過bind(2)來將一個UDP套接字綁定到一組離散的IP地址或者子網上。他認為這是一個很寬泛的問題，即如何提供更通用的接口。
Ahern解釋了當前將套接字綁定到一個VRF從設備上的方法。同時他提出了一個問題：內核接收到報文後如何選擇套接字。當前針對UDP套接字的做法是進行打分。但這一方式並不通用。
David Miller指出不同的功能域有不同的方法來完成上述工作。比如VRF層和netns層。此前Miller不希望網絡代碼中充斥著各種netns關鍵字，因為在獲得靈活性的同時會帶來很大的性能開銷。他認為不要添加新的key而是要複用已有的架構。Herbert則認為應該明確說明這一原因。最後大家的一致意見是使用IP_UNICAST_IF標記。當前該標記隻針對UDP和RAW套接字，隨後將會被擴展到TCP。
XDP和eBPF程序標識
Ahern隨後討論的問題是關於BPF的。他舉了個例子，一個經典的BPF程序：對ARP報文進行檢查。如果從過濾器讀取程序代碼，用戶會得到一係列難以解析的二進製數據。盡管內核可以輸出成類C風格，但是依然難以解析。
Ahern希望對於一個經典BPF程序是否可以恢複到原始的普通文本輸出。比如將0x806替換成常量。即便對於eBPF程序的輸出也可以進行很多的改進。Alexei Starovoitov是BPF的維護者，他認為合理的做法是給eBPF程序返回一些映射關係的信息。更加複雜的數據則留待後續解決。
當前最重要的是debug工具的開發工作，即完成一個逆編譯器將指令重構為可以閱讀的代碼。隨後是如何將數據返回到用戶態。Ahern解釋現在使用bpf(2)係統調用僅僅是將數據拷貝到不同的文件描述符。Starovoitov指出當前這樣的行為是比較合理的。
一個類似的問題是如何區分XDP程序（XDP也是通過BPF來編寫的）。Miller解釋了用戶希望有一種方法來獲得係統中安裝了哪些XDP程序。當前僅僅隻有一個SHA-1標識符來標識這些XDP程序，但是僅僅是內部使用的，並沒有暴露給用戶態。Starovoitov提到當前有一個布爾值來標識程序是否加載。
在上述問題的基礎上，如何獲取已經部署的BPF程序的代碼也成為了討論的問題。但是目前並沒有特別的結論。
IPv4/v6
主要針對內核中 IPv4/v6 的處理差異提出討論，看是否有某些層麵合並的可能，比如：
1. loopback 設備在路由表會產生不可達，VRF 的 loopback 接口目前並沒有做這樣的限製
2. anycast 路由在 VRF 上麵被增加到錯誤的接口，以及JVM 實現自己的路由表
3. 是否有可能合並 FIB tree (v4/v6 的路由層內核數據結構），其中還針對是否 v4 應該支持源路由進行討論
4. 32-bit/64-bit/128-bit 地址優化的問題
譯：基本認同 “目前很多由於協議設計的差異，v4/v6 並不是完全兼容，考慮到實現層麵，數據結構基本無法合並，但是代碼邏輯在某種層麵可以簡化和統一。”
模塊加載
主要是是否可以在驅動加載之前，為設備傳遞某些選項，比如：有些設備的 Firmware 加載之前就需要預先根據某些配置來完成早期的初始化。 提到了 devlink , 但是實際上 PCI BDF 未必能和設備一一對應，包括是否讓驅動在某種狀態等待，或者一些特殊的腳本加載過程，總之 hack 的程度比較高。
譯：這裏麵可能還要涉及到 BIOS 和早期 option ROM 加載的問題，總之，目前並沒有統一的方法，我認為這個應該 HW design 和驅動編寫的時候應該充分考慮到這一點，給自己留好 fallback 的路線，這種事情還是別指望內核了。
UAPI patches
主要是接口向後兼容性問題經常被打破的問題，這個需要有全局觀，D.M. 應該會更加嚴格的控製這些 patch 的合並，包括是否實際驗證。總之這件事是被強調了，後麵會嚴格控製。
譯：這裏並非技術本身，流程，還是流程。
數據中心硬件
主要是同一個網卡被多個主機共享，FB 已經有在自己的數據中心應用了。
會上提出了很多 concern, 主要包括安全性和穩定性，所謂訪問範圍擴大化，當然給了黑客更多的機會，另外是否會引起故障擴大化。
另外，Mellanox 和 Broadcom 也都有類似的產品，還可以研究下 Yosemite platform
譯：這些 host 網絡可以通過 PCI-e 的通道互聯之後，某些網絡延遲可以做到更小，一些特殊的計算模型會更快，帶來的肯定就是穩定性和安全的問題，還是設計平衡。還有很多很多討論了，大家有興趣去 Netconf 現場聽聽吧。
3. An update on storage standards
2017LSFMM(Linux Storage Filesystem, and Memory-Management Summit)第二個全體會議日，Fred Knight向與會人員講解了過去一年中，存儲標準方麵的進展。過去一年中，傳輸(如：光纖通信、以太網)和SCSI協議都沒有太大變化，NVMe標準則有一些更新。
在傳輸標準方麵，32Gb/128Gb的光纖通信已經開始支持，64Gb/256Gb的支持也在開發中。T級別的光纖通信也在規劃中，Knight說：如果帶寬可以達到T數量級，那就比較有趣了。同樣以太網也增加了新的帶寬支持（從2.5Gb到Tb級），同樣也有新的市場斬獲（比如：汽車）。NVMe有了新的命令集，同時支持多種連接方式可選（如：PCEe、基於以太的RDMA、InfiniBand）。
SCSI
對於SCSI， 一個簡化的捆綁狀態命令(TEST BIND)被添加。WRITE ATOMIC命令也被添加進來，這條命令允許寫操作要麼所有數據全部寫入，要麼什麼都不更改。另外，WRITE SCATTER命令添加了了一個32字節的變量。Knight說：2016LSFMM中討論的atomic與scatter的組合寫操作沒有後續更新。一些存儲廠商反對該操作，他們認為他們的理解與Linux所需要的之間存在一些差距，所以不會對該特性有更多關注。
針對流ID(stream IDs)的WRITE STREAM命令已經被添加到標準中。另外增加了BACKGROUND CONTROL命令，該命令允許對存儲設備中運行的後台任務(比如垃圾回收)進行一些控製操作。後台任務會對I/O的時間產生影響，因此用戶希望有能力通過改變參數對後台任務進行控製。
一些預定義的特性集合(例如：2010 Basic，2016 Basic，Maintenance，Provisioning)已經被確立，存儲設備廣告中可以利用這些名詞，同時主機也可以對這些特性的有效性進行檢查。Knight說：新的特性集合也會陸續被添加，這將會是個持續的過程。Ted Ts'o問：是否設備可以對外聲稱支持一些特性集合，但實現中支持了更多不屬於該特性集合中的指令？Knight回答：設備廠商可以這麼做。
Knight說：過去一年中，SCSI最大的一件事情是驅動器縮量(drive depopulation)。驅動器損壞與我們想象中的不一樣，它通常都是隻有一部分壞了。比如說：如果你有一個8TB的驅動器，該驅動器頭部的存儲空間無法工作，你可以簡單的將該驅動器前麵的部分關閉，這樣你就會擁有一個6TB大小的可以正常工作的驅動器。
不管SCSI還是ATA，“損壞重用(repurposing)”都已經支持了，驅動器在縮減容量後可以繼續工作。對於已經存儲在驅動器中的數據，要麼全部丟失，要麼被映射到其他的邏輯塊地址(LBA)中。GET PHYSICAL ELEMENT STATUS命令可以被用於確定哪些部分不能工作，新驅動器容量是多少。REMOVE ELEMENT AND TRUNCATE命令被用於關閉不能工作的存儲空間。驅動器可以被重新格式化。如果其他存儲空間再次出現問題，上述流程可以繼續重複進行。
對於讀整個驅動器並嚐試進行數據修複已經在標準中支持了很長時間。有一些命令可以提供接下來的N個邏輯塊地址(LBA)是否已經損壞的信息，這些塊可以在接下來的處理中被跳過。這些特性使得在驅動器部分損壞的情況下，允許主機盡可能的修複更多數據。
對於驅動器縮量(depopulation)，去年有一些“數據保留(data preserving)”模式的討論。這是很複雜的，因此需要更多些時間。Knight說：很多人都在問這個特性是否真的需要，所以這個特性也有可能被砍掉。
NVMe
過去的一年NVMe工作組是最忙的。麵向光纖的官方規格書已經發布。“清潔(sanitize)”命令也已經正式支持，該命令可以在將某個驅動器用於其他用途前，清除該驅動器。其他的機製，比如：加密擦除(crypto erase)和塊擦除(block erase)，則會清除所有SSD，所以那些設備不實現這些機製。
一個設備的crash-dump機製稱之為“telemetry”，已經被添加進規格書中。流ID(Stream IDs)也同樣被加入。一些對persistent reservation的支持也已經添加，但所添加的與SCSI對應特性並不兼容，這是所不希望的。一個兼容版本正在製定中。
虛擬/仿真控製器是添加的另外一個特性。這個特性允許虛擬機認為他們可以擁有自己的專用NVMe控製器。每個客戶虛擬機可以獲得一個專用的隊列，這些隊列是由hypervisor分配的。這就允許過個客戶虛擬機共享同一個物理NVMe適配器。
NVMe工作組每周的兩小時會議都有大約80人參加，並且T10(SCSI)、T11(Fibre Channel)和T13(ATA)委員會每個月都有三天的會議。有一些顧慮說這個組有做不完的事情。他說：NVMe組在逐漸加速進度，而其他組則比幾年前更穩定一些。
Mathew Wilcox問Knight如何評價在Linux中，存儲設備匯報的所有不同的錯誤都被歸結為EIO(I/O error)。Knight笑著表示問題在於存儲設備匯報的各種類型的錯誤碼和介質錯誤(譯者注：設備本來就不應匯報那麼多不同種類的錯誤)。而Martin Petersen則指出，POSIX標準需要將這些錯誤映射為EIO，因為應用無法理解其他錯誤的細節。
4. Online filesystem scrubbing and repair
Darrick J. Wong是就職於Oracle的XFS開發者。他的LSFMM session通常會討論有大量圍繞XFS的討論，本次也不例外，拋開各種雜七雜八的小話題不說，本次討論的主線圍繞XFS reverse mapping和online fsck進行。
首先讓我們看看反向索引，XFS通過名為GETFSMAP的ioctl接口來實現反向索引查詢，具體來說就是給定一個extent，找出它的屬主到底為何（數據、元數據抑或空閑沒有分配）
而反向索引和online fsck這兩者之間其實有很強的依賴關係。一般實現一個online fsck時，內核仍然mount著文件係統，隨時隨地可能修改它，為保證元數據的一致性，online fsck的主體邏輯通常隻能由內核本身來執行，在執行的過程中與其他正常的文件操作進行同步。而不是像平時offline fsck那樣純粹由一個用戶態工具來完成。Darrick Wong表示在onilne fsck的過程中，他不希望依靠盤上已有的元數據，因為理論上來說它們全都有風險，不完全可信。Darrick Wong的計劃是依靠反向索引來逐步把元數據重新建立起來。同時他還可以通過GETFSMAP + Direct IO把所有的數據塊讀一遍看看會不會有錯誤。這裏唯一的漏洞在於當依賴反向索引工作的online fsck試圖重建反射索引自身時會出死鎖，即”自指悖論“。Darrick Wong的解決辦法是在這裏對online fsck和offline fsck取一折衷：凍結所有的inodes操作，這使得online fsck頗像一個offline fsck，然後在重建的過程中慢慢逐一解凍它們。
Darrick Wong遇到的另一個問題是如何對付已經打開的fd。如果允許這些fd繼續操作，他們很可能會感知到fsck帶來的不一致。他能想到的一個辦法是摘掉這些文件對應的page cache頁，把它們的inode_operations替換掉，讓它們基本上什麼都不做直接返回錯誤。這樣處理過的inode除了被關閉進orphan list就沒別的用處了。
Chris Mason表示在Facebook沒有這類online fsck的需求，我相信絕大多數互聯網公司或者雲計算公司都不會有，一般來說高可靠性應該優先通過replication來保證，單個結點auto-healthing的難度顯然遠大於replication，並且引入了如此之高的複雜度之後可靠性到底是提升了還是下降了都尚且存疑。況且就算這條路可行，在online fsck執行的過程中很可能文件係統的各種性能都會下降，帶來較差的用戶體驗。在大型係統的設計中，我們更傾向於明確地搞清楚一個子部件的狀態，它要麼被標記成可用，就充分地完全地可用，要麼被標記成不可用，就不會有任務、請求、流量、容器或者虛擬機被調度上來，完全徹底地下線。一個半死不活正在修複自身的組件沒有人會喜歡。Darrick Wong的看法是這一類特性主要是針對那些寧可犧牲性能，也絕不能允許一個存儲服務，準確地說是一個存儲服務的結點不可用的係統準備的。
從我的角度來看，如果存在這樣一個通過期待本地文件係統永遠不出錯來實現高可用的係統，那麼它可以被稱為“根本不具備高可用性”的係統，或者“錯誤設計的高可用係統”。
5. Handling writeback errors
在2017 Linux Storage, Filesystem, and Memory Management大會上，Jeff Layton說目前Linux對writeback的錯誤處理有點混亂。他與其他參會者討論，並提出了一種方案用於更好地處理writeback error。Writeback是指先寫入緩存中，然後再落到文件係統上。
最初是他在查看Ceph文件係統時出現的ENOSPC(out of space)錯誤。他發現PG_error(這個頁flag用於標記writeback出錯)會覆蓋其他error 狀態，從而造成EIO (IO error)。這啟發了他去了解其他文件係統是如何處理這種錯誤。最後他發現目前其他文件係統對此並沒有一致的解決方案。Dmitry Monakhov認為這是因為writeback的時機太晚了，而導致ENOSPC。但是Layton說這個錯誤也會以其他方式觸發。
Layton說，如果在writeback時出錯，這個錯誤應該在用戶態調用close()或fsync()時返回告訴用戶。這些錯誤應該用struct address_space中的AS_EIO和AS_ENOSPC跟蹤。同時也被page level的PG_error跟蹤。
他也說，一個不小心的sync操作可能清除error flag，然而這些錯誤並沒有返回到用戶態。PG_error也用來跟蹤和報告讀錯誤，因此讀寫混合可能會在flag報告前丟失。另外還有一個問題，當發生wirteback error時，page做了什麼。目前，page被留在了page cache中，並標記了clean和up-to-date，因此用戶態並不知道發生了錯誤。
因此，Layton問到，遇到這種情況怎麼辦。James Bottomley也問到，文件係統想以什麼樣的細粒度來track error。Layton講到address_space是個合適的level。Jan Kara指出PG_error本打算用於讀錯誤。但Layton說到一些writeback的機製也用它。
Layton建議，清理tree來去掉PG_error對於writeback errors。這樣的話就會透過tree來看writeback上的error會不會傳播到用戶空間，或者它們是否可能被錯誤地清除。Ted Ts'o 講到，可能有必要在不發生任何錯誤下writeback，因為這些錯誤不會返回到用戶空間上。
Bottomley講到，他更不願標記page clean，如果這些page還沒有寫入磁盤上的話。這些錯誤信息有必要被跟蹤，以扇區為單位。因此block layer可以告訴文件係統bio錯誤發生在哪裏。Chris Mason建議那些做“redoing the radix tree”的人可能想提供一種方法來存儲發生在文件上的錯誤。這樣的話，錯誤就可以被報告出來，一旦報告，即可清除掉。
Layton提出一個想法。可以在address_space結構上加上writeback error counter和writeback error code fields，同時在struct file上加上writeback error counter。當有writeback error發生時，address space的writeback error counter就會自增，並記錄下error code。當fsync()或close()，這些錯誤就會被報告出來 ，不過隻在file結構裏的wirteback error counter小於address space裏的couter。這樣的話，address_space裏的counter將會被拷貝到file結構中。
Monakhov問到，為何需要counter，Layton解釋到，這樣可以更高效處理multiple overlapping error，不管是在writeback出錯在file打開時還是在最後fasync()。Ts'o 同意了這個說法。那些需要更多信息的應用應該使用O_DIRECT。而對於大多數應用程序,知道一個錯誤發生在文件哪裏是必要的;所有的應用程序需要更好的粒度已經在使用O_DIRECT。
Layton's的方法將會出現一些false positive,但是不會出現false negatives。避免false positives可能是個比較大的目標，但提出的這個方法更簡單些，副作用也少。Layton說到這種方法將會提高用戶空間的表現。
Ts’o 指出現在處理ENOMEM(out of memory)上有一些方法。如果writeback內部的error返回的話，Layton描述的一些問題也會發生。因此，一些文件係統並不會返回ENOMEM錯誤，為了避免，他們不得不使用鎖。Ts’o 已經有一些patch來推遲writeback，讓pages處於髒狀態，而不是獲得鎖，來阻止oom kills。
但是Layton認為，首要的應該是想辦法來處理wirteback error。文件係統現在避免這個問題，是因為他們現在處理不好。更好的處理temporaay error方法應該加進來。另一件需要做的事是當進行wirteback時，應該擁有更多的killable或可中斷的調用。
另外，Laytony講到，當發生writeback error，page應該做哪些。目前，是將其置為clean。如果發生一個hard error(will never be retries)，難道這個頁就無效了嗎？Ts’o講到這些頁不能一直為髒狀態，因為如果有大量writeback error，係統將會OOM。
Steve French認為error handling應該處理在higher level，但Layton講，這就像一個不清楚怎麼使用的bad api。他現在在嚐試解決，也希望開發者關注他的patches（https://lwn.net/Articles/718648/）.
6. Two new block I/O schedulers for 4.12
整個Kernel對於多隊列塊設備的支持一直存在一個短板，那就是麵向多隊列設備的IO調度器。而4.12開發周期，同時引入了兩個新的支持多隊列的IO調度器。
對於多隊設備的支持，缺乏IO調度器看上去是致命的，但事實卻是，最初對於是否需要一個調度器並不明確。高端固態設備並不存在旋轉延遲(Rotational delay，指普通磁盤中，從磁盤上讀取數據的過程中，需要磁盤旋轉所產生的延遲)問題，因此固態設備對操作的順序(Ordering)並不敏感。但IO調度即使對於最快速的設備也是有價值的。調度器可以合並相鄰的塊訪問，減少操作的次數，並且可以對不同操作進行優先級處理。所以雖然對引入一個針對多隊列設備的IO調度器期待了很久，但一直沒有相應的實現。
第一個支持多隊列IO調度的是BFQ(Budget Fair Queing)調度。這個調度器對低速設備有更好的IO響應，適合用於手機等設備中。
BFQ是在CFQ基礎上進行了改善，但將其合並仍然是一個漫長的過程。最主要的障礙就是：他是個傳統IO調度器，並非麵向多隊列調度的。塊子係統的開發者們有一個長期的目標，就是將所有驅動更改為多隊列模型。因此，合並一個對多隊列IO調度提升有限的調度器，並不合適。
過去幾個月，BFQ的開發者Paolo Valent將其代碼移植到了多隊列接口上。已知的問題都已經被解決。按照計劃，BFQ將會出現在4.12中。
BFQ是一個比較複雜的調度器，是為了提供好的交互響應而設計，尤其對於低速設備。但對於IO操作較快，吞吐量作為最主要的問題的情況下，這種複雜度變的沒有意義。固態設備需要一個更為簡單的調度器。
Kyber IO調度器正是這個定位。它隻有1000行的代碼，比BFQ簡單很多。IO請求進入Kyber中後，將被分為以讀為主的同步隊列和已寫為主的異步隊列。讀寫在應用中的行為特性使得讀的優先級高於寫，同時寫操作也不能一直處於饑餓狀態。
Kyber調度器會將所有請求送到分發隊列中，然後測量每個請求的完成時間，根據完成時間調整隊列的限製，以達到配置所需要的延時。
Kyber也已經被4.12的合並窗口接受。根據計劃，4.12內核將同時發布兩個新的針對多隊列設備的IO調度器。用戶關注響應或者應用了低速設備，可以選擇BFQ。如果用戶對吞吐更敏感，則可以選擇Kyber。
最後更新：2017-06-08 10:01:31