寫在前面

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

友情提醒：以下內(nèi)容默認(rèn)讀者已經(jīng)初步了解 task、cgroup、subsys、hierarchy 是什么及它們之間的關(guān)系。

我們?yōu)樯蛾P(guān)注 cgroup 控制平面性能？

云原生目前是云計算領(lǐng)域的重點發(fā)展方向，其中的函數(shù)計算場景中，函數(shù)執(zhí)行的速度是重要的性能指標(biāo)，要求能夠快速、高并發(fā)地創(chuàng)建和銷毀實例。在此場景下的隔離特性普遍都會涉及到大量 cgroup 的相關(guān)操作，而現(xiàn)有的cgroup框架設(shè)計并發(fā)性很差，或許在設(shè)計之初并未考慮到大規(guī)模的控制平面操作（例如：創(chuàng)建和銷毀）。而隨著技術(shù)的演進，大規(guī)模的控制平面操作場景逐漸增多，也促使我們開始更加關(guān)注控制平面的性能。

本文的闡述是基于4.19版本的內(nèi)核源代碼，旨在分析cgroup提供給用戶的接口背后的實現(xiàn)原理，并基于實現(xiàn)原理給出一些用戶態(tài)使用cgroup的建議，最后在文章的結(jié)尾分享了一些內(nèi)核態(tài)優(yōu)化的思路。

原理分析

圖一

圖二

以上兩張圖，是4.19版本的內(nèi)核中cgroup中最主要的幾個數(shù)據(jù)結(jié)構(gòu)之間的連接關(guān)系和cgroup層次結(jié)構(gòu)的連接關(guān)系。

cgroup：字面意思

cgroup_root：hierarchy

cgroup_subsys: 子系統(tǒng)，縮寫的變量一般為ss

cgroup_subsys_state: 當(dāng)指向某個subsys時，代表該subsys在某個cgroup中一個實體

css_set、cset_cgrp_link：用于建立task_struct和cgroup之間多對多的關(guān)系

這些數(shù)據(jù)結(jié)構(gòu)抽象之后是這張圖：

圖三

其實也很好理解，本質(zhì)上cgroup框架要解決的是：一個cgroup管哪些task，一個task歸哪些cgroup管的問題，在實現(xiàn)上可通過cset作為中介來建立這層關(guān)系。相比于task和cgroup直連，這種做法可以簡化復(fù)雜的關(guān)系。這是因為在實際使用的場景中，task基本都以組為單位進行管理，對某一組task的資源管控方案都大概率是一致的。

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

創(chuàng)建：在圖二所示的樹形結(jié)構(gòu)中增加一個葉節(jié)點
綁定：本質(zhì)上是遷移，子進程被fork出來時連接父進程指向的cset，綁定即是從一個cset（如果不再有task指向則刪除）遷移到了另一個cset（如果指向的是新的cgroup集合則新創(chuàng)建）
刪除：在圖二所示的樹形結(jié)構(gòu)中刪除一個不管控任何task的葉節(jié)點
對于cgroup的各類操作的訪問控制也圍繞這三類實體的展開：

task: cgroup_threadgroup_rwsem鎖
cset: css_set_lock鎖
cgroup: cgroup_mutex鎖
具體的這三類鎖有什么作用，將在優(yōu)化思路里進行分析。

優(yōu)化方案

問題出在哪？

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

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

css_set_lock保護和css_set相關(guān)的一切操作。任意進程隨時都有可能exit，導(dǎo)致某個css_set釋放，從而影響css_set的哈希表。除此之外，對cgroup的絕大多數(shù)的操作也會涉及到css_set_lock，這是因為對cgroup的絕大多數(shù)的操作（創(chuàng)建除外）都會引起css_set的變化。

cgroup_threadgroup_rwsem保護和cgroup相關(guān)的線程組操作，現(xiàn)實中隨時都有可能的fork和exit操作導(dǎo)致線程組發(fā)生變化。這里用讀寫鎖的原因是，進程自身的行為可能包括改變線程組的組成和持有讀鎖，這是可以并行的；當(dāng)進程attach的時候，需要一個穩(wěn)定的線程組視圖，此時如果進程在fork或者exit的話會導(dǎo)致線程組的改變，而attach又是可以以線程組為單位的，不可并行。這里用讀寫鎖并不是說是真的在讀什么或?qū)懯裁?，只是恰好符合讀者并行，寫者需與其他寫者互斥這個特性而已。也就是說，fork、exec、exit之間可以并行，類似于讀者；attach與其他的都互斥，類似于寫者。

這三個鎖會受到進程fork和exit的影響，并且也會導(dǎo)致對cgroup的任何操作之間幾乎不可并行。筆者在對cgroup進行深入的研究前，覺得是最開始的設(shè)計者偷懶，使用如此大粒度的鎖，直到把cgroup的框架摸索明白后才發(fā)現(xiàn)，臨界區(qū)就是有這么大，各種會異步發(fā)生的事件都需要操作這些數(shù)據(jù)，所以這些鎖被設(shè)計成這樣也很合理。

這里試著對問題進行抽象，思考一下問題的本質(zhì)在哪。

對于cgroup_mutex，問題本質(zhì)是樹形（節(jié)點是cgroup）結(jié)構(gòu)的并發(fā)訪問。

對于css_set_lock，問題其實是二部圖（一邊是css_set，一邊是cgroup）結(jié)構(gòu)的并發(fā)訪問。

對于cgroup_threadgroup_rwsem，問題其實是集合（線程組作為集合的元素）結(jié)構(gòu)的并發(fā)訪問。

問題的定義已經(jīng)清楚了，怎么解決呢？以我目前的能力，我沒法解。

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

雖然治本難治，但治標(biāo)還是可以有點想法的。

用戶態(tài)優(yōu)化：減少cgroup操作

這個方案很好理解，提前把cgroup創(chuàng)建和配置好，等需要用的時候直接取就行。這個方案效果極好，簡直是降維打擊。這里貼一下實驗數(shù)據(jù)，這里的測試模擬袋鼠容器啟動時的創(chuàng)建與讀寫——

這個方案達到了90%以上的優(yōu)化率，將本來需要創(chuàng)建配置后attach進程最后刪除的情況變成了只需要attach，工作量少了，自然也就變快了。

但這個方案存在一些弊端。一方面，池子里不用的cgroup對于系統(tǒng)來講依然是可見的，需要進行管理，因此會存在一定的負(fù)載；另一方面是數(shù)據(jù)殘留問題，并不是所有的subsys都提供類似于clear的操作接口，如果對監(jiān)控數(shù)據(jù)有要求的話cgroup就是用一次就廢，需要對池子進行補充，增加控制邏輯的同時又出現(xiàn)了競爭，效果會打折扣。最后便是需要明確cgroup的層次結(jié)構(gòu)，畢竟要提前創(chuàng)建和配置，如果對運行時的層次結(jié)構(gòu)無法掌控的話，池子都沒法建立。

減少cgroup數(shù)量

systemd在默認(rèn)情況下會把大多數(shù)subsys都掛在獨立的一個hierarchy下，如果業(yè)務(wù)的進程都需要受同一些subsys管控的話，可以把這些subsys都掛載在同一個hierarchy下，比如把cpu、memory、blkio掛載在一起。

這時候可能有同學(xué)要問了，原本在cpu、memory、blkio下各創(chuàng)建一個cgroup，和在cpu_memory_blkio下創(chuàng)建一個cgroup能有多少區(qū)別？該有的邏輯都得有，一個都跑不了，最多就是少了幾個cgroup自身這個結(jié)構(gòu)體，能有多少區(qū)別？

這里要回歸到最開始的場景，cgroup的問題出在場景是高并發(fā)，而本質(zhì)上各類操作卻是串行的。我們知道，衡量性能有主要的兩個維度：吞吐和延遲。cgroup本質(zhì)的串行無法直接提高吞吐，各個subsys獨立在hierarchy下等于是被拆解成子任務(wù)，反而提高了延遲。

下面是測試數(shù)據(jù)：

內(nèi)核態(tài)優(yōu)化

對上述三把鎖動不了，只能對臨界區(qū)內(nèi)的那部分內(nèi)容下手了。想要縮小臨界區(qū)，那就需要找出臨界區(qū)內(nèi)耗時的部分進行優(yōu)化。

下圖是各個子系統(tǒng)創(chuàng)建cgroup時各個部分的耗時：

這里簡單解釋下各個部分做了些什么：

cgroup：創(chuàng)建和初始化cgroup結(jié)構(gòu)體
kernfs：創(chuàng)建cgroup的目錄
populoate：創(chuàng)建cgroup控制用的文件接口
cssalloc：分配css
cssonline：css在各個子系統(tǒng)中的online邏輯
csspopulate：創(chuàng)建子系統(tǒng)控制用的文件接口
從圖中可以發(fā)現(xiàn)cpu、cpuacct、memory的耗時相對于其他的子系統(tǒng)延遲高很多，其中css alloc和css populate占大頭。下面我們將研究一下這個“主要矛盾“究竟在做些什么。

通過分析我們發(fā)現(xiàn)，css alloc上延遲高是因為給一些percpu的成員分配內(nèi)存，這一過程比較耗時。css populate上是因為部分子系統(tǒng)的接口文件比較多，需要依次一個個地創(chuàng)建從而消耗更多的時間。

分析過后發(fā)現(xiàn)，這些邏輯都是必須沒有冗余，怎么優(yōu)化？做緩存唄。percpu成員變量記錄下地址不釋放下次重復(fù)使用，子系統(tǒng)接口文件在釋放時以文件夾為單位移到一個指定的地方，需要時再移回來，只涉及目錄文件上一個目錄項的讀寫，開銷低且是常數(shù)。

通過這兩種方式，各個創(chuàng)建cgroup的延時優(yōu)化結(jié)果如下：

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

縮小臨界區(qū)后雖然并不能對并發(fā)度有什么影響，但至少延遲降下來了，下面是測試數(shù)據(jù)。

t個線程并發(fā)，每個線程在cpu、cpuacct、cpuset、memory、blkio下創(chuàng)建n個cgroup：

一些假想

如果無視各種限制因素，拋棄現(xiàn)有的框架，不考慮向下兼容，實現(xiàn)一個用于管控進程資源且支持高并發(fā)的框架，可以怎么設(shè)計？

現(xiàn)在cgroup的機制提供了相當(dāng)高的靈活性，子系統(tǒng)之間的關(guān)系可以隨意綁定，task可以隨意綁在任意一個cgroup上，如果犧牲一下這些靈活性，對問題的解釋是不是就可以變得簡單點，下面談?wù)勎业膸讉€想法。

第一，前文提到的為了減少cgroup數(shù)量，把所有的子系統(tǒng)都綁定在一起的想法，是否可以固化在內(nèi)核當(dāng)中，或者說不提供子系統(tǒng)獨立掛載和綁定掛載的特性？這樣，進程組與cgroup變成了一一對應(yīng)的關(guān)系，cset就沒有了存在的意義，css_set_lock帶來的問題也不攻自破。但是對應(yīng)的弊端是，一個進程組內(nèi)的所有進程在每個子系統(tǒng)上資源控制都是一致的。

第二，cgroup層級結(jié)構(gòu)是否有存在的必要？現(xiàn)在cgroup以樹形結(jié)構(gòu)組織，確實在邏輯上更加符合現(xiàn)實。比如，在第一層給業(yè)務(wù)分配總資源，在第二層給業(yè)務(wù)的各個組件分配資源。但在操作系統(tǒng)分配資源的視角上，以及業(yè)務(wù)進程具體獲得資源的視角上，第一層的存在并沒什么作用，只是給用戶提供了邏輯更清晰的運維管理。如果把cgroup v2提出的no internal process特性也應(yīng)用上，可以把cgroup層級扁平化到只有一層。

cgroup只有一層的好處是，可以很方便地把cgroup_mutex粒度細(xì)化，細(xì)化到每個cgroup一把鎖，不會存在好幾層的樹形結(jié)構(gòu)——改動一個cgroup需要從祖先開始持鎖的問題。鎖的粒度細(xì)化后，在并發(fā)啟動容器實例的時候，因為對應(yīng)不同的cgroup，也就不會存在競爭的問題。

第三，cgroup的刪除能否加以限制？現(xiàn)在是用戶異步手動刪除空的cgroup，如果可以在cgroup不再管理進程（exit，move）時隱藏，后續(xù)找個時機觸發(fā)刪除，便可以少一個競爭場景。這種方法會造成空的cgroup沒法再利用，現(xiàn)在有對空cgroup再利用的需求嗎？

最后，綁定進程能否加以限制？task綁定cgroup的本質(zhì)是移動，從一個cgroup到另一個cgroup。cgroup_mutex粒度細(xì)化后會存在ABBA的死鎖問題。有一個問題是，task存在綁定到一個cgroup后再綁定的需求嗎？理想情況是綁定一個后順利運行然后退出?；谶@種假設(shè)就可以做一個限制，只允許task在綁定時，src與dst內(nèi)必須包含default cgroup、default cgroup起一個跳板作用。

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

最后

本文中提到的一些優(yōu)化技術(shù)目前集成進入 Alibaba Cloud Linux [2] 中，并已經(jīng)在云原生場景中得到進一步應(yīng)用。

附

[1] cgroup 相關(guān)官方文檔

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

[2] Alibaba Cloud Linux：

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