寫在前面

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

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

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

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

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

原理分析

圖一

圖二

以上兩張圖，是4.19版本的內(nèi)核中cgroup中最主要的幾個(gè)數(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)指向某個(gè)subsys時(shí)，代表該subsys在某個(gè)cgroup中一個(gè)實(shí)體

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

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

圖三

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

對(duì)于cgroup的各類操作圍繞著這三類實(shí)體展開：

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

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

優(yōu)化方案

問(wèn)題出在哪？

問(wèn)題在于三個(gè)鎖上：cgroup_mutex、cgroup_threadgroup_rwsem、css_set_lock。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

減少cgroup數(shù)量

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

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

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

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

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

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

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

這里簡(jiǎn)單解釋下各個(gè)部分做了些什么：

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

通過(guò)分析我們發(fā)現(xiàn)，css alloc上延遲高是因?yàn)榻o一些percpu的成員分配內(nèi)存，這一過(guò)程比較耗時(shí)。css populate上是因?yàn)椴糠肿酉到y(tǒng)的接口文件比較多，需要依次一個(gè)個(gè)地創(chuàng)建從而消耗更多的時(shí)間。

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

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

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

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

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

一些假想

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

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

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

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

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

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

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

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

最后

本文中提到的一些優(yōu)化技術(shù)目前集成進(jìn)入 Alibaba Cloud Linux [2] 中，并已經(jīng)在云原生場(chǎng)景中得到進(jìn)一步應(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