LWN:新增misc cgroup!
關(guān)注了就能看到更多這么棒的文章哦~
The misc control group
By Jake Edge
May 18, 2021
DeepL assisted translation
https://lwn.net/Articles/856438/
控制組(cgroups, control groups)是用來限制系統(tǒng)中的進(jìn)程對(duì)共享資源的訪問的。哪些資源呢?比如說用于指定虛擬機(jī)(VM)中的加密過的內(nèi)存區(qū)域要使用的一個(gè) ID 信息,例如 AMD 安全加密虛擬化(SEV,Secure Encrypted Virtualization)功能所使用的地址空間標(biāo)識(shí)符(ASIDs,address-space identifiers)。Vipin Sharma 早在 9 月份的時(shí)候就著手為這些 ASIDs 增加一個(gè) cgroup。不過后來收到反饋之后,他將這個(gè)想法擴(kuò)展為一個(gè)可以跟蹤和限制任何可以計(jì)數(shù)(count)的資源的 controller 了。這個(gè) patch set 最終形成了 misc cgroup 的控制器,并且已經(jīng)合入,會(huì)被包含在 Linux 5.13。
其基本思想是允許管理員(或云端管理系統(tǒng))對(duì) cgroup 中的進(jìn)程所能使用的這些 ID 的數(shù)量實(shí)施限制。在云環(huán)境中,這些進(jìn)程一般就是對(duì)應(yīng)那些正在 KVM 下運(yùn)行的虛擬機(jī)。在最初發(fā)布 ASIDs 的時(shí)候,Sean Christopherson 建議增大 controller 的管理范圍來包含更多種類的加密 ID,而不僅僅局限于 AMD SEV 使用的 ID。英特爾也有一個(gè)類似的信任域擴(kuò)展(TDX,Trust Domain Extension)功能,同樣使用了 key ID,因此同樣也是一個(gè)可能需要管理起來的有限資源。s390 架構(gòu)也有類似的安全執(zhí)行 ID(SEID,secure execution ID)。這些 ID 可能不如其他類似的 ID 那么稀缺,但是如果有一個(gè) controller 來控制分配的話也是有好處的。
這些信息促使 Sharma 將原本計(jì)劃實(shí)現(xiàn)的 controller 進(jìn)行了擴(kuò)展,變得更加通用以便讓 TDX ID 和 SEID 也能用起來。到 1 月份的時(shí)候,"encryption ID controller" 這個(gè) patch set 已經(jīng)發(fā)出了第 4 個(gè)版本,但維護(hù)者 Tejun Heo 有點(diǎn)擔(dān)心在 cgroup 子系統(tǒng)中增加這些特定硬件相關(guān)的控制開關(guān):
我很不愿意接受跟特定廠商有關(guān)的接口,原因有幾個(gè),但其中最重要的是這些接口通常意味著之前沒有充分做好抽象化,或者真實(shí)的需求沒有充分分析和開發(fā),而且這些接口在一段時(shí)間后往往會(huì)成為包袱。
他和 Sharma 在討論中進(jìn)行了不少交流,但最終 Heo 說,由于 encryption ID 的前景還不明確,他還是希望能換一個(gè)不同的方法來實(shí)現(xiàn)。與其讓這個(gè) controller 專門用于管理 encryption ID,不如把它變成一個(gè)用來管理某個(gè) cgroup(或整個(gè)系統(tǒng))中有數(shù)量限制的資源的通用 controller:"所以,最終結(jié)果上來說,與之前提出的代碼并沒有什么不同,只是讓他變成了一個(gè)通用的 misc controller。"
Sharma 同意了這個(gè)計(jì)劃,并在 2 月中旬發(fā)布了一個(gè) misc controller 的 RFC 補(bǔ)丁。之后又發(fā)布了三個(gè)版本,不過 controller 的形式基本上再?zèng)]有變過了。這些 patch 還增加了 SEV ASIDs 和相關(guān)的(但不是相同的概念)SEV Encrypted State(SEV-ES)IDs 的改動(dòng),把它們兩個(gè)作為采用這種方式控制數(shù)量的資源。在具有相關(guān)功能的 AMD CPU 上,如果用 CONFIG_CGROUP_MISC 構(gòu)建內(nèi)核,那么 root control group 就會(huì)有一個(gè) misc.capacity 文件,顯示每個(gè)類別中的可用 ID 的數(shù)量:
$ cat misc.capacity
sev 50
sev_es 10
假如有個(gè)系統(tǒng)中有兩個(gè)被此 controller 管理的資源,名稱分別為 "res_a "和 "res_b",那么在 cgroup 目錄結(jié)構(gòu)中將會(huì)展示這兩個(gè)值。其中 misc.capacity 這個(gè) root file 是只讀的,其中記錄了整個(gè)系統(tǒng)中有多少數(shù)量的相關(guān)資源,另外有兩個(gè)文件會(huì)出現(xiàn)在 non-root 的 cgroup 中,可以用來限制資源以及監(jiān)控使用了多少:
$ cat misc.current
res_a 3
res_b 0
$ cat misc.max
res_a 10
res_b 4
從名字也可以看出,misc.current 指出了這個(gè) group 當(dāng)前的使用情況,而 misc.max 則指出了這個(gè) group 中所允許的最大使用量被設(shè)置為多少。misc.max 與其他兩個(gè)文件不同,它是一個(gè)可讀可寫的文件,所以如果要設(shè)置最大值的話可以這樣寫:
# echo res_a 1 > misc.max
# echo res_b max > misc.max
第一個(gè)命令會(huì)將 res_a 的最大值設(shè)置為 1,而第二個(gè)將 res_b 設(shè)置為這個(gè) group 中所允許的最大值(由其父控制組進(jìn)行限制的話就可能小于系統(tǒng)最大值)。
添加兩種類型的 SEV ASID 的 patch 展示了如何向 controller 添加其他要管理的資源(比如 TDX ID 或 SEID)。先在 misc_res_types 這個(gè) enum 中增加一項(xiàng),并把相應(yīng)的名字添加到 misc_res_names 數(shù)組中。在資源可被分配使用之前,必須先初始化一下來設(shè)置全系統(tǒng)有多少資源可用:
int misc_cg_set_capacity(enum misc_res_type type, unsigned long capacity);
當(dāng)需要使用或者釋放其中某個(gè)資源時(shí),可以使用 charge(意指收費(fèi))以及 uncharge(意指不再收費(fèi)) API:
int misc_cg_try_charge(enum misc_res_type type, struct misc_cg *cg,
unsigned long amount);
void misc_cg_uncharge(enum misc_res_type type, struct misc_cg *cg,
unsigned long amount);
有一點(diǎn)需要注意的是,按照 cgroup v2 的設(shè)計(jì),在將一個(gè)進(jìn)程遷移(migrate)到另一個(gè)不同的 cgroup 時(shí)并不改變統(tǒng)計(jì)信息。此進(jìn)程之前分配獲取到資源時(shí)候所在的 cgroup 會(huì)一直保持對(duì)這個(gè)進(jìn)程的數(shù)據(jù)統(tǒng)計(jì)以及 charge 狀態(tài),直到資源被釋放為止。調(diào)用者函數(shù)(caller)需要跟蹤記錄被 charge 的 cgroup,這樣才能在后面對(duì)正確的 cgroup 進(jìn)行 uncharge。在代碼 review 過程中有討論過要不要讓 charge 關(guān)系跟隨進(jìn)程一起遷移。Jacob Pan 提出也把 charge 關(guān)系一起遷移,因?yàn)樗诳紤]使用 misc controller 來限制通過 DMA 用于 I/O 的 ASIDs(IOASIDs)。Heo 明確指出不對(duì) misc controller 進(jìn)行 charge 關(guān)系的遷移:
請(qǐng)注意,cgroup2 總體上并不喜歡、支持 charge 關(guān)系的遷移,甚至連普通遷移也不贊同。我們?cè)?cgroup1 上嘗試了 memcg,結(jié)果很糟糕。文檔中描述的預(yù)期使用場(chǎng)景是使用遷移來孵化一個(gè) cgroup(或者甚至更理想的情況是使用新的 clone 系統(tǒng)調(diào)用來在指定的 cgroup 中啟動(dòng)進(jìn)程),直到退出為止。所有現(xiàn)存的 controller 都假定是按這種使用模式來工作的,所以除非有一些非常有說服力的理由否則我應(yīng)該不會(huì)贊同偏離這個(gè)方向的做法。
在進(jìn)程獲得 IOASIDs 之后,很可能沒有什么真正使用場(chǎng)景需要遷移進(jìn)程,所以 Pan 還是打算使用 misc contoller,至少目前是這樣決定的。
事實(shí)上,正如 Heo 所說,misc 控制器有一點(diǎn) "讓步方案(cop-out)"的意思。他不相信這些硬件功能今后會(huì) "永遠(yuǎn)" 存在,所以他不愿意將 cgroup 子系統(tǒng)跟它們永遠(yuǎn)關(guān)聯(lián)起來:
我判斷,這些底層的硬件特性還沒有成熟到可以在它們上面建立合理的抽象。隨著時(shí)間的推移,也許未來的發(fā)展會(huì)讓硬件達(dá)到這樣的程度,當(dāng)然也許這些功能很快也就會(huì)消失于是人們都不會(huì)記得有這么個(gè)功能。
但是,不管是不是個(gè)讓步方案,Misc controller 現(xiàn)在已經(jīng)開始用起來了??雌饋磉€會(huì)有其他幾個(gè)地方可能打算使用這個(gè) misc controller。在未來幾個(gè)月里,很可能會(huì)出現(xiàn)更多的使用場(chǎng)景。對(duì)于簡(jiǎn)單的資源,也就是只需要對(duì)其數(shù)量進(jìn)行跟蹤和限制的話,那么 misc controller 可以很好地完成這項(xiàng)工作。
全文完
LWN 文章遵循 CC BY-SA 4.0 許可協(xié)議。
長(zhǎng)按下面二維碼關(guān)注,關(guān)注 LWN 深度文章以及開源社區(qū)的各種新近言論~
