​簡介：io_uring 作為一種新型高效能非同步程式設計框架，代表著 Linux 核心未來的方向，當前仍處於快速發展中。阿里雲聯合 InfoQ 發起《io_uring 介紹及應用實踐》的技術公開課，圍繞 OpenAnolis 龍蜥社群 Anolis OS 8 全方位解析高效能儲存場景。

​

寫在前面

cgroup 作為容器底層技術的半壁江山，很多文章已經介紹並總結得很好了，關於 cgroup 是什麼、有什麼用以及一些相關概念，這些內容並不是本文的重點所以也將不再贅述。

友情提醒：以下內容預設讀者已經初步瞭解 task、cgroup、subsys、hierarchy 是什麼及它們之間的關係。

我們為啥關注 cgroup 控制平面效能？

雲原生目前是雲端計算領域的重點發展方向，其中的函式計算場景中，函式執行的速度是重要的效能指標，要求能夠快速、高併發地建立和銷燬例項。在此場景下的隔離特性普遍都會涉及到大量 cgroup 的相關操作，而現有的cgroup框架設計併發性很差，或許在設計之初並未考慮到大規模的控制平面操作（例如：建立和銷燬）。而隨著技術的演進，大規模的控制平面操作場景逐漸增多，也促使我們開始更加關注控制平面的效能。

本文的闡述是基於4.19版本的核心原始碼，旨在分析cgroup提供給使用者的介面背後的實現原理，並基於實現原理給出一些使用者態使用cgroup的建議，最後在文章的結尾分享了一些核心態優化的思路。

原理分析

​

圖一

​

圖二

以上兩張圖，是4.19版本的核心中cgroup中最主要的幾個資料結構之間的連線關係和cgroup層次結構的連線關係。

cgroup：字面意思

cgroup_root：hierarchy

cgroup_subsys: 子系統，縮寫的變數一般為ss

cgroup_subsys_state: 當指向某個subsys時，代表該subsys在某個cgroup中一個實體

css_set、cset_cgrp_link：用於建立task_struct和cgroup之間多對多的關係

這些資料結構抽象之後是這張圖：

​

圖三

其實也很好理解，本質上cgroup框架要解決的是

對於cgroup的各類操作圍繞著這三類實體展開：

• 建立：在圖二所示的樹形結構中增加一個葉節點
• 繫結：本質上是遷移，子程序被fork出來時連線父程序指向的cset，繫結即是從一個cset（如果不再有task指向則刪除）遷移到了另一個cset（如果指向的是新的cgroup集合則新建立）
• 刪除：在圖二所示的樹形結構中刪除一個不管控任何task的葉節點

對於cgroup的各類操作的訪問控制也圍繞這三類實體的展開：

• task: cgroup_threadgroup_rwsem鎖
• cset: css_set_lock鎖
• cgroup: cgroup_mutex鎖

具體的這三類鎖有什麼作用，將在優化思路里進行分析。

優化方案

問題出在哪？

問題在於三個鎖上：cgroup_mutex、cgroup_threadgroup_rwsem、css_set_lock。

cgroup_mutex保護cgroup的整個層級結構。cgroup的層級結構是一個森林，我們需要用這個一個鎖來保護整個森林。改變層級結構比如常見的mount、mkdir、rmdir就不必多說了，肯定是需要持有這個鎖的；除此之外對cgroup的任何一個其他的操作也需要持有這個鎖，比如attach task、以及其他的讀或寫cgroup提供的介面。同時，因為rmdir的操作是隨時都有可能發生的，任何操作都需要與rmdir都互斥。

css_set_lock保護和css_set相關的一切操作。任意程序隨時都有可能exit，導致某個css_set釋放，從而影響css_set的雜湊表。除此之外，對cgroup的絕大多數的操作也會涉及到css_set_lock，這是因為對cgroup的絕大多數的操作（建立除外）都會引起css_set的變化。

cgroup_threadgroup_rwsem保護和cgroup相關的執行緒組操作，現實中隨時都有可能的fork和exit操作導致執行緒組發生變化。這裡用讀寫鎖的原因是，程序自身的行為可能包括改變執行緒組的組成和持有讀鎖，這是可以並行的；當程序attach的時候，需要一個穩定的執行緒組檢視，此時如果程序在fork或者exit的話會導致執行緒組的改變，而attach又是可以以執行緒組為單位的，不可並行。這裡用讀寫鎖並不是說是真的在讀什麼或寫什麼，只是恰好符合讀者並行，寫者需與其他寫者互斥這個特性而已。也就是說，fork、exec、exit之間可以並行，類似於讀者；attach與其他的都互斥，類似於寫者。

這三個鎖會受到程序fork和exit的影響，並且也會導致對cgroup的任何操作之間幾乎不可並行。筆者在對cgroup進行深入的研究前，覺得是最開始的設計者偷懶，使用如此大粒度的鎖，直到把cgroup的框架摸索明白後才發現，臨界區就是有這麼大，各種會非同步發生的事件都需要操作這些資料，所以這些鎖被設計成這樣也很合理。

這裡試著對問題進行抽象，思考一下問題的本質在哪。

對於cgroup_mutex，問題本質是樹形（節點是cgroup）結構的併發訪問。

對於css_set_lock，問題其實是二部圖（一邊是css_set，一邊是cgroup）結構的併發訪問。

對於cgroup_threadgroup_rwsem，問題其實是集合（執行緒組作為集合的元素）結構的併發訪問。

問題的定義已經清楚了，怎麼解決呢？以我目前的能力，我沒法解。

是的，分析了這麼多給的結論是此題無解，或者說暫時無解，可以有的解法也會對cgroup的框架造成刮骨療毒式的改動。這背後的風險、穩定性的影響、投入產出比的痛能不能承受的住，我給不出一個確定的結論。如果讀者有什麼想法，歡迎在留言區提出，一起交流。

雖然治本難治，但治標還是可以有點想法的。

使用者態優化：減少cgroup操作

這個方案很好理解，提前把cgroup建立和配置好，等需要用的時候直接取就行。這個方案效果極好，簡直是降維打擊。這裡貼一下實驗資料，這裡的測試模擬袋鼠容器啟動時的建立與讀寫——

這個方案達到了90%以上的優化率，將本來需要建立配置後attach程序最後刪除的情況變成了只需要attach，工作量少了，自然也就變快了。

但這個方案存在一些弊端。一方面，池子裡不用的cgroup對於系統來講依然是可見的，需要進行管理，因此會存在一定的負載；另一方面是資料殘留問題，並不是所有的subsys都提供類似於clear的操作介面，如果對監控資料有要求的話cgroup就是用一次就廢，需要對池子進行補充，增加控制邏輯的同時又出現了競爭，效果會打折扣。最後便是需要明確cgroup的層次結構，畢竟要提前建立和配置，如果對執行時的層次結構無法掌控的話，池子都沒法建立。

減少cgroup數量

systemd在預設情況下會把大多數subsys都掛在獨立的一個hierarchy下，如果業務的程序都需要受同一些subsys管控的話，可以把這些subsys都掛載在同一個hierarchy下，比如把cpu、memory、blkio掛載在一起。

這時候可能有同學要問了，原本在cpu、memory、blkio下各建立一個cgroup，和在cpu_memory_blkio下建立一個cgroup能有多少區別？該有的邏輯都得有，一個都跑不了，最多就是少了幾個cgroup自身這個結構體，能有多少區別？

這裡要回歸到最開始的場景，cgroup的問題出在場景是高併發，而本質上各類操作卻是序列的。我們知道，衡量效能有主要的兩個維度：吞吐和延遲。cgroup本質的序列無法直接提高吞吐，各個subsys獨立在hierarchy下等於是被拆解成子任務，反而提高了延遲。

下面是測試資料：

核心態優化

對上述三把鎖動不了，只能對臨界區內的那部分內容下手了。想要縮小臨界區，那就需要找出臨界區內耗時的部分進行優化。

下圖是各個子系統建立cgroup時各個部分的耗時：

​

​

這裡簡單解釋下各個部分做了些什麼：

• cgroup：建立和初始化cgroup結構體
• kernfs：建立cgroup的目錄
• populoate：建立cgroup控制用的檔案介面
• cssalloc：分配css
• cssonline：css在各個子系統中的online邏輯
• csspopulate：建立子系統控制用的檔案介面

從圖中可以發現cpu、cpuacct、memory的耗時相對於其他的子系統延遲高很多，其中css alloc和css populate佔大頭。下面我們將研究一下這個“主要矛盾“究竟在做些什麼。

通過分析我們發現，css alloc上延遲高是因為給一些percpu的成員分配記憶體，這一過程比較耗時。css populate上是因為部分子系統的介面檔案比較多，需要依次一個個地建立從而消耗更多的時間。

分析過後發現，這些邏輯都是必須沒有冗餘，怎麼優化？做快取唄。percpu成員變數記錄下地址不釋放下次重複使用，子系統介面檔案在釋放時以資料夾為單位移到一個指定的地方，需要時再移回來，只涉及目錄檔案上一個目錄項的讀寫，開銷低且是常數。

通過兩種方式，各個建立cgroup的延時優化結果如下：

​

cpu子系統css alloc部分依然比較耗時的原因在於初始化操作比較多，但相比於原先的160us，延時已經降到了50us。

縮小臨界區後雖然並不能對併發度有什麼影響，但至少延遲降下來了，下面是測試資料。

t個執行緒併發，每個執行緒在cpu、cpuacct、cpuset、memory、blkio下建立n個cgroup：

一些假想

如果無視各種限制因素，拋棄現有的框架，不考慮向下相容，實現一個用於管控程序資源且支援高併發的框架，可以怎麼設計？

現在cgroup的機制提供了相當高的靈活性，子系統之間的關係可以隨意繫結，task可以隨意綁在任意一個cgroup上，如果犧牲一下這些靈活性，對問題的解釋是不是就可以變得簡單點，下面談談我的幾個想法。

第一，前文提到的為了減少cgroup數量，把所有的子系統都繫結在一起的想法，是否可以固化在核心當中，或者說不提供子系統獨立掛載和繫結掛載的特性？這樣，程序組與cgroup變成了一一對應的關係，cset就沒有了存在的意義，css_set_lock帶來的問題也不攻自破。但是對應的弊端是，一個程序組內的所有程序在每個子系統上資源控制都是一致的。

第二，cgroup層級結構是否有存在的必要？現在cgroup以樹形結構組織，確實在邏輯上更加符合現實。比如，在第一層給業務分配總資源，在第二層給業務的各個元件分配資源。但在作業系統分配資源的視角上，以及業務程序具體獲得資源的視角上，第一層的存在並沒什麼作用，只是給使用者提供了邏輯更清晰的運維管理。如果把cgroup v2提出的no internal process特性也應用上，可以把cgroup層級扁平化到只有一層。

cgroup只有一層的好處是，可以很方便地把cgroup_mutex粒度細化，細化到每個cgroup一把鎖，不會存在好幾層的樹形結構——改動一個cgroup需要從祖先開始持鎖的問題。鎖的粒度細化後，在併發啟動容器例項的時候，因為對應不同的cgroup，也就不會存在競爭的問題。

第三，cgroup的刪除能否加以限制？現在是使用者非同步手動刪除空的cgroup，如果可以在cgroup不再管理程序（exit，move）時隱藏，後續找個時機觸發刪除，便可以少一個競爭場景。這種方法會造成空的cgroup沒法再利用，現在有對空cgroup再利用的需求嗎？

最後，繫結程序能否加以限制？task繫結cgroup的本質是移動，從一個cgroup到另一個cgroup。cgroup_mutex粒度細化後會存在ABBA的死鎖問題。有一個問題是，task存在繫結到一個cgroup後再繫結的需求嗎？理想情況是繫結一個後順利執行然後退出。基於這種假設就可以做一個限制，只允許task在繫結時，src與dst內必須包含default cgroup、default cgroup起一個跳板作用。

上面這些都是我一些不成熟的想法，歡迎討論。

原文連結
本文為阿里雲原創內容，未經允許不得轉載。

​