簡介：?io_uring 作為一種新型高性能異步編程框架，代表著 Linux 內(nèi)核未來的方向，當(dāng)前仍處于快速發(fā)展中。阿里云聯(lián)合 InfoQ 發(fā)起《io_uring 介紹及應(yīng)用實(shí)踐》的技術(shù)公開課，圍繞 OpenAnolis 龍蜥社區(qū) Anolis OS 8 全方位解析高性能存儲(chǔ)場景。

寫在前面

cgroup 作為容器底層技術(shù)的半壁江山，很多文章已經(jīng)介紹并總結(jié)得很好了，關(guān)于 cgroup 是什么、有什么用以及一些相關(guān)概念，這些內(nèi)容并不是本文的重點(diǎn)所以也將不再贅述。

友情提醒：以下內(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ì)算場景中，函數(shù)執(zhí)行的速度是重要的性能指標(biāo)，要求能夠快速、高并發(fā)地創(chuàng)建和銷毀實(shí)例。在此場景下的隔離特性普遍都會(huì)涉及到大量 cgroup 的相關(guān)操作，而現(xiàn)有的cgroup框架設(shè)計(jì)并發(fā)性很差，或許在設(shè)計(jì)之初并未考慮到大規(guī)模的控制平面操作（例如：創(chuàng)建和銷毀）。而隨著技術(shù)的演進(jìn)，大規(guī)模的控制平面操作場景逐漸增多，也促使我們開始更加關(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之間多對多的關(guān)系

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

圖三

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

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

• 創(chuàng)建：在圖二所示的樹形結(jié)構(gòu)中增加一個(gè)葉節(jié)點(diǎn)
• 綁定：本質(zhì)上是遷移，子進(jìn)程被fork出來時(shí)連接父進(jìn)程指向的cset，綁定即是從一個(gè)cset（如果不再有task指向則刪除）遷移到了另一個(gè)cset（如果指向的是新的cgroup集合則新創(chuàng)建）
• 刪除：在圖二所示的樹形結(jié)構(gòu)中刪除一個(gè)不管控任何task的葉節(jié)點(diǎn)

對于cgroup的各類操作的訪問控制也圍繞這三類實(shí)體的展開：

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

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

優(yōu)化方案

問題出在哪？

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

cgroup_mutex保護(hù)cgroup的整個(gè)層級結(jié)構(gòu)。cgroup的層級結(jié)構(gòu)是一個(gè)森林，我們需要用這個(gè)一個(gè)鎖來保護(hù)整個(gè)森林。改變層級結(jié)構(gòu)比如常見的mount、mkdir、rmdir就不必多說了，肯定是需要持有這個(gè)鎖的；除此之外對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的哈希表。除此之外，對cgroup的絕大多數(shù)的操作也會(huì)涉及到css_set_lock，這是因?yàn)閷group的絕大多數(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又是可以以線程組為單位的，不可并行。這里用讀寫鎖并不是說是真的在讀什么或?qū)懯裁?#xff0c;只是恰好符合讀者并行，寫者需與其他寫者互斥這個(gè)特性而已。也就是說，fork、exec、exit之間可以并行，類似于讀者；attach與其他的都互斥，類似于寫者。

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

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

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

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

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

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

是的，分析了這么多給的結(jié)論是此題無解，或者說暫時(shí)無解，可以有的解法也會(huì)對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è)方案效果極好，簡直是降維打擊。這里貼一下實(shí)驗(yàn)數(shù)據(jù)，這里的測試模擬袋鼠容器啟動(dòng)時(shí)的創(chuàng)建與讀寫——

線程數(shù)	循環(huán)次數(shù)	優(yōu)化后時(shí)間/s	優(yōu)化前時(shí)間/s
1	2000	0.09	2.18
10	200	0.08	1.78
40	50	0.12	1.89
200	10	0.14	2.22

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

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

減少cgroup數(shù)量

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

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

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

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

線程數(shù)	循環(huán)次數(shù)	優(yōu)化后時(shí)間/s	優(yōu)化前時(shí)間/s
1	2000	0.99	2.18
10	200	0.89	1.78
40	50	0.98	1.89
200	10	1.00	2.22

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

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

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

這里簡單解釋下各個(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í)相對于其他的子系統(tǒng)延遲高很多，其中css alloc和css populate占大頭。下面我們將研究一下這個(gè)“主要矛盾“究竟在做些什么。

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

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

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

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

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

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

t	n	使用緩存平均時(shí)間	不使用緩存平均時(shí)間	優(yōu)化率
20	100	0.23s	0.71s	67.6%
20	1000	2.66s	8.12s	67.3%
200	10	0.18s	0.54s	66.7%
200	100	2.00s	7.30s	72.4%

t	n	使用緩存長尾時(shí)間	不使用緩存長尾時(shí)間	優(yōu)化率
20	100	0.29s	0.88s	67.1%
20	1000	3.25s	9.37s	65.3%
200	10	0.32s	0.94s	66.0%
200	100	3.40s	9.53s	64.3%

一些假想

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

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

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

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

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

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

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

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

原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。?

總結(jié)

以上是生活随笔為你收集整理的长文解析：作为容器底层技术的半壁江山， cgroup如何突破并发创建瓶颈？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。