寫在前面

cgroup 作為容器底層技術的半壁江山，很多文章已經介紹并總結得很好了，關于 cgroup 是什么、有什么用以及一些相關概念，這些內容并不是本文的重點所以也將不再贅述。大家如有興趣，可以搜索各路技術文章了解或直接參考官方文檔 [1]。

友情提醒：以下內容默認讀者已經初步了解 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管哪些task，一個task歸哪些cgroup管的問題，在實現上可通過cset作為中介來建立這層關系。相比于task和cgroup直連，這種做法可以簡化復雜的關系。這是因為在實際使用的場景中，task基本都以組為單位進行管理，對某一組task的資源管控方案都大概率是一致的。

對于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起一個跳板作用。

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

最后

本文中提到的一些優化技術目前集成進入 Alibaba Cloud Linux [2] 中，并已經在云原生場景中得到進一步應用。

附

[1] cgroup 相關官方文檔

https://man7.org/linux/man-pages/man7/cgroups.7.html

[2] Alibaba Cloud Linux：

https://www.aliyun.com/product/alinux