寫在前面
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建立和配置好，等需要用的時候直接取就行。這個方案效果極好，簡直是降維打擊。這裡貼一下實驗資料，這裡的測試模拟袋鼠容器啟動時的建立與讀寫——
| 線程數 | 循環次數 | 優化後時間/s | 優化前時間/s |
| 1 | 2000 | 0.09 | 2.18 |
| 10 | 200 | 0.08 | 1.78 |
| 40 | 50 | 0.12 | 1.89 |
| 0.14 | 2.22 |
這個方案達到了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下等于是被拆解成子任務，反而提高了延遲。
下面是測試資料：
| 0.99 | |||
| 0.89 | |||
| 0.98 | |||
核心态優化
對上述三把鎖動不了，隻能對臨界區内的那部分内容下手了。想要縮小臨界區，那就需要找出臨界區内耗時的部分進行優化。
下圖是各個子系統建立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：
| t | n | 使用緩存平均時間 | 不使用緩存平均時間 | 優化率 |
| 20 | 100 | 0.23s | 0.71s | 67.6% |
| 1000 | 2.66s | 8.12s | 67.3% | |
| 0.18s | 0.54s | 66.7% | ||
| 2.00s | 7.30s | 72.4% |
| 使用緩存長尾時間 | 不使用緩存長尾時間 | |||
| 0.29s | 0.88s | 67.1% | ||
| 3.25s | 9.37s | 65.3% | ||
| 0.32s | 0.94s | 66.0% | ||
| 3.40s | 9.53s | 64.3% |
一些假想
如果無視各種限制因素，抛棄現有的架構，不考慮向下相容，實作一個用于管控程序資源且支援高并發的架構，可以怎麼設計？
現在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（完）
加入龍蜥社群
加入微信群：添加社群助理-龍蜥社群小龍（微信：openanolis_assis），備注【龍蜥】拉你入群；加入釘釘群：可掃碼或搜釘釘群号（33311793）。歡迎開發者/使用者加入龍蜥OpenAnolis社群交流，共同推進龍蜥社群的發展，一起打造一個活躍的、健康的開源作業系統生态！
龍蜥社群_小龍 釘釘群二維碼
關于龍蜥社群
龍蜥社群是由企事業機關、高等院校、科研機關、非營利性組織、個人等按照自願、平等、開源、協作的基礎上組成的非盈利性開源社群。龍蜥社群成立于2020年9月，旨在建構一個開源、中立、開放的Linux上遊發行版社群及創新平台。
短期目标是開發Anolis OS作為CentOS替代版，重新建構一個相容國際Linux主流廠商發行版。中長期目标是探索打造一個面向未來的作業系統，建立統一的開源作業系統生态，孵化創新開源項目，繁榮開源生态。
加入我們，一起打造面向未來的開源作業系統！
Https：//openanolis.cn