CGROUPS（7）Linux程序員手冊CGROUPS（7）
NAME 頂部
cgroups-Linux控制組
控制組（通常稱爲cgroup）是Linux內核
允許將流程組織爲分層的功能
然後可以限制其使用各種類型資源的組
並進行監控。內核的cgroup接口通過
僞文件系統，稱爲cgroupfs。分組是在
核心cgroup內核代碼，而資源跟蹤和限制是
在一組每個資源類型的子系統（內存，CPU，
等等）。
術語
一個cgroup中是進程的集合綁定到一組
通過cgroup文件系統定義的限制或參數。
一個子系統是一個內核組件，修改的行爲
cgroup中的進程。已經實現了各種子系統，
使諸如限制CPU數量之類的事情成爲可能
cgroup可用的時間和內存，佔CPU時間
由cgroup使用，並凍結和恢復執行
cgroup中的進程。子系統有時也稱爲
資源控制器（或簡稱爲控制器）。
控制器的cgroup按層次結構排列。這個
通過創建，刪除和重命名來定義層次結構
cgroup文件系統中的子目錄。在每個級別
可以定義層次結構，屬性（例如限制）。極限
控制和cgroup提供的會計通常有效
在cgroup下的整個子層次結構中
屬性已定義。因此，例如，對
層次結構中較高級別的cgroup不能超過
後代cgroups。
Cgroups版本1和版本2
cgroups實現的最初版本是在Linux中
2.6.24。隨着時間的推移，各種cgroup控制器已添加到
允許管理各種類型的資源。但是，那
這些控制器的開發在很大程度上是不協調的，
結果導致控制器和控制器之間出現許多不一致之處
cgroup層次結構的管理變得相當複雜。（一個
這些問題的詳細描述可以在內核中找到。
源文件Documentation / cgroup-v2.txt。）
由於最初的cgroups實現存在問題
（cgroups版本1）從Linux 3.10開始，開始了新的工作，
正交實施來解決這些問題。最初標記
實驗性的，並隱藏在-o __DEVEL__sane_behavior掛載後面
選項，最終制作了新版本（cgroups版本2）
正式發佈的Linux 4.5。兩者之間的差異
版本在以下文本中描述。文件
cgroups v1中存在的cgroup.sane_behavior是此安裝的遺物
選項。該文件始終報告爲“ 0”，並且僅保留用於向後
兼容性。
儘管cgroups v2旨在替代cgroups v1，但是
較舊的系統繼續存在（出於兼容性原因，
不太可能被刪除）。目前，cgroups v2僅實現
cgroups v1中可用的控制器子集。兩個系統
已實現，因此v1控制器和v2控制器都可以
安裝在同一系統上。因此，例如，可以使用
在版本2下受支持的控制器，同時
使用版本2尚不支持的版本1控制器
這些控制器。唯一的限制是控制器
不能同時在cgroups v1層次結構和
在cgroups v2層次結構中。
CGROUPS版本1 頂部
在cgroups v1下，每個控制器可以單獨安裝
cgroup文件系統，提供了自己的層次結構
系統上的進程。也可以合併多個
（甚至所有）cgroup v1控制器針對同一cgroup
文件系統，這意味着共同安裝的控制器可以管理相同的文件系統
流程的分層組織。
對於每個已安裝的層次結構，目錄樹都會鏡像該控件
組層次結構。每個對照組均由一個目錄表示，
每個子控件cgroup都表示爲一個子控件
目錄。例如，/ user / joe / 1.session表示控件
group 1.session，它是cgroup joe的子級，後者是/ user的子級
。每個cgroup目錄下都有一組文件，可以
讀或寫，反映了資源限制和一些常規
cgroup屬性。
任務（線程）與進程
之間的關係在cgroups v1中，對進程和task進行了區分。
在此視圖中，一個流程可以包含多個任務（更常見的是
從用戶空間的角度來看，稱爲線程，並且在
此手冊頁的其餘部分）。在cgroups v1中，可以
獨立地處理線程中的cgroup成員資格
處理。
cgroups v1能夠在不同cgroup之間拆分線程
在某些情況下造成了問題。例如，對於
內存控制器，因爲進程的所有線程共享一個
單個地址空間。由於這些問題，
獨立地處理線程中的cgroup成員資格
最初的cgroups v2實施中刪除了該流程，並且
隨後以更有限的形式恢復（請參見
下面的“線程模式”。
掛載v1控制器要
使用cgroup，需要使用CONFIG_CGROUP構建的內核
選項。此外，每個v1控制器都有一個關聯的
必須設置才能使用該配置選項
控制器。
爲了使用v1控制器，必須將其安裝在cgroup上
文件系統。此類掛載的通常位置是
在/ sys / fs / cgroup掛載的tmpfs（5）文件系統下。因此，可能會掛載CPU
控制器如下：
掛載-t cgroup -o cpu無/ sys / fs / cgroup / cpu
可以將多個控制器安裝在同一個層次上
拱形。例如，這裏的cpu和cpuacct控制器是
與單個層次結構共同安裝：
掛載-t cgroup -o cpu，cpuacct無/ sys / fs / cgroup / cpu，cpuacct
掛載控制器的作用是使一個進程處於同一狀態
所有組合控制器的cgroup。分開安裝
控制器允許一個控制器的進程位於cgroup / foo1中
而在另一個/ foo2 / foo3中。
可以將所有v1控制器安裝在同一層級上
希
掛載-t cgroup -o全部cgroup / sys / fs / cgroup
（通過省略-o all可以達到相同的結果，因爲它是
如果未明確指定任何控制器，則爲默認值。）
無法將同一控制器安裝在多個
cgroup層次結構。例如，不可能同時安裝兩個
將cpu和cpuacct控制器針對一個層次結構進行安裝單獨針對另一個層次結構
的cpu控制器。有可能的
創建完全相同的一組安裝點
共裝控制器。但是，在這種情況下，所有結果都是
提供了相同層次結構視圖的多個安裝點。
請注意，在許多系統上，v1控制器會自動
安裝在/ sys / fs / cgroup下；特別是systemd（1）自動
創建此類安裝點。
卸載v1控制器
可以使用umount（8） com 卸載已安裝的cgroup文件系統。
命令，如以下示例所示：
卸載/ sys / fs / cgroup / pids
但請注意：cgroup文件系統只有在未卸載時才被卸載
忙，也就是說，它沒有子cgroup。如果不是這樣，
那麼umount（8）的唯一作用是使安裝不可見。
因此，要確保真正刪除安裝點，必須
首先刪除所有子cgroup，然後依次刪除
所有成員進程都已從這些cgroup移到了根目錄
cgroup。
Cgroups版本1控制器
每個cgroups版本1控制器均由內核控制。
配置選項（在下面列出）。此外，可用性
cgroups功能的功能由CONFIG_CGROUPS內核con-控制
圖形化選項。
cpu（自Linux 2.6.24起; CONFIG_CGROUP_SCHED）
可以保證Cgroup的“ CPU共享”數量最少
系統繁忙時。這不限制cgroup的CPU
CPU不忙時的使用率。有關更多信息，請參見
Documentation / scheduler / sched-design-CFS.txt。
在Linux 3.2中，此控制器已擴展爲提供CPU
“帶寬”控制。如果內核配置有CON-
FIG_CFS_BANDWIDTH，則每個調度週期內（定義
通過cgroup目錄中的文件），可以定義
分配給一個進程中的CPU時間的上限
cgroup。即使沒有其他限制，此上限也適用
爭奪CPU。有關更多信息，請參見
內核源文件Documentation / scheduler / sched-bwc.txt。
cpuacct（從Linux 2.6.24開始; CONFIG_CGROUP_CPUACCT）
這樣可以按進程組統計CPU使用率。
可以在內核源文件中找到更多信息。
Documentation / cgroup-v1 / cpuacct.txt。
cpuset（從Linux 2.6.24開始; CONFIG_CPUSETS）
該cgroup可用於將cgroup中的進程綁定到
指定的一組CPU和NUMA節點。
可以在內核源文件中找到更多信息。
Documentation / cgroup-v1 / cpusets.txt。
內存（從Linux 2.6.25開始; CONFIG_MEMCG）
內存控制器支持報告和限制
cgroup使用的進程內存，內核內存和交換。
可以在內核源文件中找到更多信息。
Documentation / cgroup-v1 / memory.txt。
設備（自Linux 2.6.26起；CONFIG_CGROUP_DEVICE）
這支持控制可能創建的進程（mknod）
設備以及打開它們以進行讀取或寫入。的
可以將策略指定爲允許列表和拒絕列表。
強制實施層次結構，因此新規則不得違反現有規則
目標或祖先cgroup的規則。
可以在內核源文件中找到更多信息。
Documentation / cgroup-v1 / devices.txt。
冷凍機（自Linux 2.6.28起; CONFIG_CGROUP_FREEZER）
該冷凍 cgroup中可以暫停和恢復（恢復）所有親
cgroup中的成功。凍結cgroup / A也會導致
例如，/ A / B中的子進程將被凍結。
可以在內核源文件中找到更多信息。
Documentation / cgroup-v1 / freezer-subsystem.txt。
net_cls（從Linux 2.6.29開始; CONFIG_CGROUP_NET_CLASSID）
這會將爲cgroup指定的classid放置在網絡上
由cgroup創建的數據包。然後可以使用這些classid
在防火牆規則中，以及
tc（8）。這僅適用於離開cgroup的數據包，不適用於
到達cgroup的流量。
可以在內核源文件中找到更多信息。
Documentation / cgroup-v1 / net_cls.txt。
blkio（因爲Linux 2.6.33; CONFIG_BLK_CGROUP）
所述blkio cgroup中控制和限制訪問指定的塊
通過以節流和
葉節點和中間節點的上限
存儲層次結構。
有兩種策略。首先是成比例的
CFQ實現的基於權重的磁盤時間劃分。這個
對於使用CFQ的葉節點有效。第二個是a
調整策略，該策略指定對服務器的I / O速率上限
設備。
可以在內核源文件中找到更多信息。
Documentation / cgroup-v1 / blkio-controller.txt。
perf_event（從Linux 2.6.39開始; CONFIG_CGROUP_PERF）
此控制器允許PERF監視所述一組處理的
分組在cgroup中。
可以在內核源文件中找到更多信息。
tools / perf / Documentation / perf-record.txt。
net_prio（從Linux 3.3開始; CONFIG_CGROUP_NET_PRIO）
這樣就可以爲每個網絡接口指定優先級，
對於cgroups。
可以在內核源文件中找到更多信息。
Documentation / cgroup-v1 / net_prio.txt。
hugetlb（從Linux 3.5開始; CONFIG_CGROUP_HUGETLB）
這支持限制cgroup使用大頁面。
可以在內核源文件中找到更多信息。
Documentation / cgroup-v1 / hugetlb.txt。
pids（從Linux 4.3開始; CONFIG_CGROUP_PIDS）
該控制器允許限制處理數量
可以在cgroup（及其後代）中創建。
可以在內核源文件中找到更多信息。
Documentation / cgroup-v1 / pids.txt。
rdma（從Linux 4.11開始; CONFIG_CGROUP_RDMA）
RDMA控制器允許限制RDMA / IB-spe-的使用
每個cgroup的重要資源。
可以在內核源文件中找到更多信息。
Documentation / cgroup-v1 / rdma.txt。
創建cgroup和移動進程
一個cgroup文件系統最初包含一個根cgroup，“ /”，
所有進程都屬於哪個 通過創建一個新的cgroup
cgroup文件系統中的目錄：
mkdir / sys / fs / cgroup / cpu / cg1
這將創建一個新的空cgroup。
通過將其PID寫入進程，可以將進程移至該cgroup。
cgroup的cgroup.procs文件：
回聲$$> /sys/fs/cgroup/cpu/cg1/cgroup.procs
一次只能將一個PID寫入該文件。
將值0 寫入cgroup.procs文件會導致寫入過程
移到相應的cgroup。
將PID寫入cgroup.procs時，進程中的所有線程
立即移到新的cgroup中。
在層次結構中，一個進程可以恰好是一個cgroup的成員。
將進程的PID寫入cgroup.procs文件會自動刪除
它來自以前是其成員的cgroup。
該cgroup.procs文件可以被閱讀，以便獲取進程的列表
是cgroup的成員。返回的PID列表不安全
事前要有條理。也不能保證沒有重複
牛。（例如，當從
清單。）
在cgroups v1中，可以通過以下方式將單個線程移至另一個cgroup：
寫入其線程ID（即，由返回的內核線程ID
clone（2）和gettid（2））到cgroup目錄中的任務文件。
可以讀取此文件以發現屬於成員的線程集
cgroup的
刪除cgroup
要刪除cgroup，它必須首先沒有子cgroup並且包含
沒有（非殭屍）進程。只要是這種情況，就可以
刪除相應的目錄路徑名。請注意
cgroup目錄不能也不需要刪除。
Cgroups v1發佈通知
可以使用兩個文件來確定內核是否提供通知。
cgroup變空時發生故障。一個cgroup被認爲是
當它不包含子cgroup和成員進程時爲空。
每個cgroup層次結構的根目錄中的一個特殊文件，
release_agent，可用於註冊程序的路徑名
當層次結構中的cgroup變爲空時可以調用。的
新的空cgroup的路徑名（相對於cgroup安裝
點）作爲唯一的命令行參數，當
release_agent程序被調用。該release_agent程序可能
刪除cgroup目錄，或者用一個進程重新填充它。
release_agent文件
的默認值爲空，表示沒有
釋放代理被調用。
也可以通過以下方式指定release_agent文件
的內容：
掛載cgroup文件系統時的掛載選項：
安裝-o release_agent =路徑名...
無論是否release_agent程序被調用時，一個特定的
cgroup變爲空是由
相應cgroup目錄中的notify_on_release文件。如果
該文件包含值0，則release_agent程序不是
調用。如果包含值1，則release_agent程序爲
調用。根cgroup中此文件的默認值爲0。
在創建新的cgroup時，此文件中的值爲
從父cgroup中的相應文件繼承。
Cgroup v1命名層次結構
在cgroups v1中，可以掛載一個沒有
連接的控制器：
mount -t cgroup -o none，name = somename none / some / mount / point
可以安裝此類層次結構的多個實例。每個層次
必須具有唯一的名稱。這種層次結構的唯一目的是
跟蹤流程。（請參閱下面的發佈通知討論。）
這樣的一個示例是使用的name = systemd cgroup層次結構
通過systemd（1）來跟蹤服務和用戶會話。
從Linux 5.0開始，cgroup_no_v1內核引導選項（已描述
如下所示）可用於通過指定方式禁用名爲cgroup v1的層次結構
fying cgroup_no_v1 =命名。
CGROUPS版本2 頂部
在cgroups v2中，所有安裝的控制器都駐留在一個統一的控制器中
層次結構。雖然（不同的）控制器可以同時
安裝在v1和v2層次結構下，則無法安裝
在v1和v2下同時使用同一控制器
層次結構。
下面總結了cgroups v2中的新行爲。
以下小節中將詳細闡述這些案例。
1. Cgroups v2提供了一個統一的層次結構，所有
控制器已安裝。
2.不允許“內部”過程。除了
根cgroup，進程只能駐留在葉節點（
本身不包含子cgroup）。詳細是
比這更微妙的，將在下面進行描述。
3.必須通過文件cgroup.controllers
和cgroup.subtree_control指定活動的cgroup 。
4. 任務文件已被刪除。此外，
cgroup.clone_children由所使用的文件cpuset
控制器已被刪除。
5.通知空cgroup的一種改進機制是
由cgroup.events文件提供。
有關更多更改，請參閱以下文檔中的Documentation / cgroup-v2.txt文件：
內核源代碼。
上面列出的一些新行爲進行了後續修改
在Linux 4.14中增加了“線程模式”（如下所述）。
Cgroups v2統一層次結構
在cgroups v1中，可以掛載不同控制器的功能
不同的層次結構旨在爲
應用程序設計。但是，實際上，靈活性
比預期的有用，並且在許多情況下增加了複雜性。
因此，在cgroups v2中，將安裝所有可用的控制器。
針對單個層次結構。可用的控制器是
自動安裝，這意味着沒有必要（或可能）
在掛載cgroup v2文件系統時指定控制器
使用如下命令：
掛載-t cgroup2無/ mnt / cgroup2
僅當cgroup v2控制器不在當前位置時纔可用
通過針對cgroup v1層次結構的安裝使用。或者，放東西
換句話說，不可能採用相同的控制器
v1層次結構和統一的v2層次結構。這意味着
可能首先需要卸載v1控制器（如前所述）
以上）在v2中可用該控制器之前。由於systemd（1）
默認情況下大量使用某些v1控制器，在某些情況下
使用選定的v1控制器啓動系統的情況更簡單
能夠。爲此，請在ker‐上指定cgroup_no_v1 = list選項。
nel boot命令行；list是逗號分隔的名稱列表
控制器以禁用，或單詞all禁用所有v1 con-
拖釣者。（這種情況已由systemd（1）正確處理，
在沒有指定控制器的情況下恢復運行。）
請注意，在許多現代系統上，在引導過程中，systemd（1）會自動將
cgroup2文件系統掛載在/ sys / fs / cgroup / unified上。
Cgroups v2掛載選項
在掛載Cgroups v2時，可以指定以下選項（mount -o）
組v2文件系統：
nsdelegate（從Linux 4.15開始）
將cgroup名稱空間視爲委託邊界。對於
詳細信息，請參見下文。
memory_localevents（從Linux 5.2開始）
該memory.events應該顯示的統計數據只針對該cgroup
本身，而不適用於任何後代cgroup。這是
Linux 5.2之前的行爲。從Linux 5.2開始，默認
行爲是要包括以下方面的統計信息：
memory.events，此安裝選項可用於還原爲
傳統行爲。此選項是系統範圍的，可以
設置爲掛載或僅從初始開始通過重新掛載進行修改
掛載命名空間；它在非初始名稱中被靜默忽略-
步伐。
的cgroup v2的控制器
下面控制器，內核源文件中記錄Docu-
心理狀態/ cgroup中-v2.txt，在cgroup中版本2的支持：
cpu（自Linux 4.15起）
這是後繼版本1 的CPU和cpuacct CON組
拖釣者。
cpuset（從Linux 5.0開始）
這是版本1 cpuset控制器的後繼產品。
冷凍機（自Linux 5.2起）
這是版本1 冷凍機控制器的後繼產品。
hugetlb（自Linux 5.6起）
這是版本1 Hugetlb控制器的後繼產品。
io（從Linux 4.5開始）
這是版本1 blkio控制器的後繼產品。
內存（自Linux 4.5起）
這是版本1 內存控制器的後繼產品。
perf_event（從Linux 4.11開始）
這與版本1 perf_event控制器相同。
pids（從Linux 4.5開始）
這與版本1 pids控制器相同。
rdma（從Linux 4.11開始）
這與版本1 rdma控制器相同。
沒有直接等效的net_cls和net_prio控制器
從cgroups版本1開始。相反，已將支持添加到
iptables（8）允許掛鉤在cgroup v2路徑名上的eBPF過濾器
根據每個cgroup決定網絡流量。
v2 設備控制器不提供接口文件。代替，
通過連接eBPF（BPF_CGROUP_DEVICE）pro 門來控制設備控制
克到v2 cgroup。
Cgroups v2子樹控件
v2層次結構中的每個cgroup包含以下兩個文件：
cgroup.controllers
此只讀文件公開了以下控制器的列表：
在此cgroup中可用。該文件的內容與父級中cgroup.subtree_control文件的
內容
cgroup。
cgroup.subtree_control
這是控制器中處於活動狀態（啓用）的控制器的列表。
cgroup。此文件中的控制器集是以下內容的子集此cgroup
的cgroup.controllers中的集合。一套
通過將字符串寫入此文件來修改活動控制器
包含以空格分隔的控制器名稱，每個名稱前都有
“ +”（啓用控制器）或“-”（禁用控制器），
如以下示例所示：
回聲'+ pids -memory'> x / y / cgroup.subtree_control
嘗試啓用不存在的控制器
寫入時，cgroup.controllers導致ENOENT錯誤
該cgroup.subtree_control文件。
因爲cgroup.subtree_control中的控制器列表是一個子集
這些cgroup.controllers中的一個，已在
層次結構中的一個cgroup永遠不能在子樹中重新啓用
低於該cgroup。
cgroup的cgroup.subtree_control文件確定con-的集合
在子 cgroup 中行使的拖釣者。當控制器
（例如pids）存在於par-的cgroup.subtree_control文件中
ent cgroup，然後輸入相應的控制器接口文件（例如，
pids.max）是在該cgroup的子級中自動創建的
並且可用於在子cgroup中施加資源控制。
Cgroups v2“沒有內部流程”規則
Cgroups v2強制執行所謂的“無內部流程”規則。
粗略地說，這條規則意味着，除了
根cgroup，進程只能駐留在葉節點（
本身不包含子cgroup）。這樣就避免了
決定如何在屬於成員的進程之間分配資源
cgroup A的過程和A的子cgroup中的進程。
例如，如果cgroup / cg1 / cg2存在，則進程可以駐留在/ cg1 / cg2中，但不能駐留
在/ cg1中。這是爲了避免cgroups中的歧義
v1關於流程之間的資源委派
/ cg1及其子cgroup。cgroups v2中推薦的方法
是爲任何非葉子 cgroup 創建一個名爲leaf的子目錄，
應該包含進程，但不能包含子cgroup。因此，流程
以前本來應該進入/ cg1的內容，現在應該進入
/ cg1 / leaf。這具有使關係明確的優點-
在/ cg1 / leaf和/ cg1的其他子進程之間傳送。
實際上，“沒有內部流程”規則比規定的要微妙得多
以上。更確切地說，規則是（非根）cgroup不能
兩者（1）具有成員流程，並且（2）將資源分配到
子cgroup-即具有一個非空的cgroup.subtree_control文件。
因此，它是可能的cgroup中同時具有構件的過程和
子cgroup，但在可以爲該cgroup啓用控制器之前，
成員進程必須移出cgroup（例如，也許
進入子cgroup）。
在Linux 4.14中增加了“線程模式”（如下所述）後，
在某些情況下，“無內部流程”規則已經放寬。
Cgroups v2 cgroup.events文件
v2層次結構中的每個非根cgroup都包含一個只讀文件，
cgroup.events，其內容爲鍵值對（以new-分隔
行字符，鍵和值之間用空格隔開）provid-
有關cgroup的狀態信息：
$ cat mygrp / cgroup.events
填充1
凍結的0
以下密鑰可能會出現在此文件中：
填充
如果此cgroup或以下任意一項，則此鍵的值爲1
它的後代具有成員進程，否則爲0。
凍結的（自Linux 5.2起）
如果此cgroup當前處於凍結狀態，則此密鑰的值爲1，
否則爲0。
該cgroup.events文件可以被監控，以便接收notifi-
當其鍵之一的值更改時出現陽離子。這樣的監控
可以用做inotify的（7） ，該通知改變爲IN_MODIFY
事件或輪詢（2） ，通過返回其通知變化POLLPRI
和POLLERR位在revents中字段。
Cgroup v2發佈通知
Cgroups v2提供了一種新的機制，可以在以下情況下獲取通知：
cgroup變爲空。V1中的cgroup release_agent和
notify_on_release文件將被刪除，並通過更換填充
在關鍵cgroup.events文件。該密鑰的值爲0，
表示cgroup（及其後代）不包含（非殭屍）
成員進程，或1，表示cgroup（或其其中之一）
後代）包含成員進程。
cgroups v2發行通知機制提供以下內容
與cgroups v1 release_agent機制相比的優勢：
*它允許更便宜的通知，因爲單個過程可以
監視多個cgroup.events文件（使用該技術
如前所述）。相比之下，cgroups v1機制
需要花費爲每個通知創建流程的費用。
*可以委派不同cgroup子層次結構的通知
到不同的過程。相比之下，cgroups v1機制
整個層次結構僅允許一個發佈代理。
Cgroups v2 cgroup.stat文件
v2層次結構中的每個cgroup都包含一個只讀cgroup.stat文件
（在Linux 4.14中首次引入），由包含以下內容的行組成
鍵值對。當前在文件中顯示以下密鑰：
nr_descendants
這是可見（即活着的）後代的總數
該cgroup下的cgroup。
nr_dying_descendants
這是在以下情況下垂死的後代cgroup的總數：
在這個cgroup中。一個cgroup在進入死亡狀態後
被刪除。保持該狀態的時間未定義
期間（取決於系統負載）
在銷燬cgroup之前將其釋放。注意存在
處於垂死狀態的某些cgroup是正常的，不是
指示任何問題。
進程不能成爲垂死的cgroup的成員，並且
垂死的cgroup無法重生。
限制後代cgroup的數量
v2層次結構中的每個cgroup包含以下文件，這些文件
可用於查看和設置後代數量限制
該cgroup下的cgroup：
cgroup.max.depth（從Linux 4.14開始）
該文件定義了降序嵌套深度的限制
dant cgroups。該文件中的值爲0表示沒有降序
可以創建dant cgroup。嘗試創建降序
嵌套級別超出限制的dant失敗（mkdir（2）
失敗，並顯示錯誤EAGAIN）。
將字符串“ max”寫入此文件意味着沒有限制
施加。該文件的默認值爲“ max”。
cgroup.max.descendants（從Linux 4.14開始）
該文件定義了活後代的數量限制
該cgroup可能具有的cgroup。嘗試創造更多
子孫超出限制所允許的數量失敗（mkdir（2）失敗
錯誤EAGAIN）。
將字符串“ max”寫入此文件意味着沒有限制
施加。該文件的默認值爲“ max”。
CGROUPS委派：將層次結構委託給較少的特權用戶
在cgroup的上下文中，委派意味着通過對
cgroup層次結構的某些子樹提供給非特權用戶。
Cgroups v1提供基於文件權限的委派支持
在cgroup層次結構中，但包含規則不如
v2（如下所述）。Cgroups v2支持包含約束的委派
通過明確的設計。本節中的討論重點是
關於在cgroups v2中的委派，對於cgroups v1有一些區別
一路注意到。
爲了描述委派，需要一些術語。一個
委託者是擁有父級cgroup的特權用戶（即root）。
一個代理方是誰將會被授予一個非特權用戶
在該父級下管理某些子層次結構所需的權限
cgroup，稱爲委託子樹。
要執行委派，委派者創建某些目錄並
代表可寫的文件，通常是通過更改所有權
的對象作爲委託者的用戶ID。假設我們
想委託植根於（例如）/ dlgt_grp的層次結構，
該cgroup下還沒有任何子cgroup，所有權
以下內容更改爲委託人的用戶ID：
/ dlgt_grp
更改子樹根的所有權意味着
在子樹下創建的任何新cgroup（及其文件
包含）也將由代表所有。
/dlgt_grp/cgroup.procs
更改此文件的所有權意味着委託人
可以將進程移到委託子樹的根中。
/dlgt_grp/cgroup.subtree_control（僅限cgroups v2）
更改此文件的所有權意味着委託人
可以啓用控制器（存在於
/dlgt_grp/cgroup.controllers），以便進一步重新分發
子樹中較低級別的資源。（作爲備選
要更改此文件的所有權，委託者可能
而是將選定的控制器添加到此文件中。）
/dlgt_grp/cgroup.threads（僅限cgroups v2）
如果有線程，則必須更改此文件的所有權
委託子樹（請參閱“線程的描述
模式”，以下）。這允許委託人編寫線程ID
到文件。（此文件的所有權也可以更改
委派域子樹時，但目前這沒有用
目的，因爲如下所述，無法移動
通過將其線程ID寫入域cgroup之間的線程
該cgroup.threads文件。）
在cgroups v1中，相應的文件應爲
委託的是任務文件。
該delegater應該不會改變任何的所有權
控制器接口文件（例如，pids.max，memory.high）在
dlgt_grp。這些文件是從
委託子樹以便將資源分配到子樹中，
並且代表不應該有權更改資源
分佈到委託子樹中。
另請參閱/ sys / kernel / cgroup / delegate文件中的討論
有關有關cgroups v2中其他可刪除文件的信息的註釋。
執行上述步驟後，代表可以
在委託子樹中創建子cgroup（cgroup
子目錄及其包含的文件將歸
委託），並在子樹中的cgroup之間移動進程。如果dlgt_grp / cgroup.subtree_control
中存在某些控制器，或者
該文件的所有權已傳遞給委託人，委託人
也可以控制相應的進一步重新分配
資源放入委託的子樹中。
Cgroups V2委派：nsdelegate和cgroup命名空間
從Linux 4.13開始，還有另一種執行cgroup的方法
cgroups v2層次結構中的委派。這是通過安裝或
使用nsdelegate掛載選項重新掛載cgroup v2文件系統。
例如，如果已經安裝了cgroup v2文件系統，則我們
可以使用nsdelegate選項將其重新掛載，如下所示：
掛載-t cgroup2 -o重新掛載，nsdelegate \
無/ sys / fs / cgroup / unified
該安裝選項的作用是使cgroup名稱空間
自動成爲委派界限。更具體地說，
以下限制適用於cgroup名稱中的進程
步伐：
*寫入控制器接口文件的根目錄中
名稱空間將失敗，並顯示錯誤EPERM。內部流程
cgroup名稱空間仍可以寫入根目錄中的可代理文件
cgroup名稱空間的目錄，例如cgroup.procs和
cgroup.subtree_control，並且可以在以下目錄下創建子層次結構
根目錄。
*嘗試跨名稱空間邊界遷移進程
被拒絕（錯誤ENOENT）。cgroup內部的進程
命名空間仍然可以（取決於所描述的包含規則
下面）在子層次結構內的cgroup之間移動進程
在名稱空間根目錄下。
將cgroup命名空間定義爲委託邊界的能力
使cgroup命名空間更有用。要了解原因，假設
我們已經有一個cgroup層次結構已委派給
非特權用戶cecilia，使用舊的委託技術
如上所述。進一步假設塞西莉亞想進一步消除
在現有的委託層次結構下劃分一個子層次結構。（對於
例如，委派的層次結構可能與非特權cecilia
運行的有條件的容器。）即使cgroup命名空間是
之所以使用，是因爲這兩個層次結構均由非特權用戶擁有
塞西莉亞，可以執行以下非法操作：
*較低層級中的流程可能會更改資源配置
該層次結構的根目錄中的Troller設置。（這些
資源控制器設置旨在允許進行控制
從上級 cgroup 行使；孩子內心的過程
cgroup不允許修改它們。）
*下級層次結構中的流程可能會將流程移入
如果上級的cgroups不在下級中
層次結構以某種方式可見。
使用nsdelegate掛載選項可以防止這兩種情況
能力。
該nsdelegate在執行時安裝選項只有一個效果
初始安裝名稱空間；在其他安裝名稱空間中，該選項是
默默無視。
注意：在某些系統上，systemd（1）自動掛載cgroup v2
文件系統。爲了試驗nsdelegate操作，它
使用以下命令行啓動內核可能會很有用
選項：
cgroup_no_v1 =所有systemd.legacy_systemd_cgroup_controller
這些選項導致內核使用cgroups v1 con-引導。
拖曳器已禁用（這意味着控制器在
v2層次結構），並告訴systemd（1）不要安裝和使用cgroup
v2層次結構，以便可以手動安裝v2層次結構
啓動後所需的選項。
Cgroup委派遏制規則
一些委派遏制規則可確保代表可以移動
委託子樹中cgroup之間的進程，但不能
將過程從委託子樹的外部移到子樹中，或者
反之亦然。非特權進程（即，委託人）可以編寫
僅在以下情況下，“目標”進程的PID 才進入cgroup.procs文件：
以下是正確的：
*作者具有對cgroup.procs文件中的寫權限。
目標cgroup。
*作者具有對cgroup.procs文件中的寫權限。
源和目標cgroup的最接近的共同祖先。
請注意，在某些情況下，最接近的共同祖先可能是
源或目標cgroup本身。這個要求不是
對cgroups v1層次結構強制執行，結果是
v1中的限制不如v2中嚴格。（例如，在
cgroups v1擁有兩個不同的委託子級別的用戶
chies可以在層次結構之間移動流程。）
*如果使用nsdelegate掛載了cgroup v2文件系統
選項，編寫者必須能夠查看源和目標
cgroup名稱空間中的cgroups。
*在cgroups v1中：編寫者的有效UID（即delega-
tee）匹配tar的真實用戶ID或保存的set-user-ID
得到過程。在Linux 4.11之前，此要求也適用於
cgroups v2（這是繼承自
cgroups v1，後來被認爲是不必要的，因爲另一個
規則足以將其包含在cgroups v2中。）
注意：這些委派遏制規則的後果之一是：
無特權的代表不能將第一個過程放入
委託子樹 相反，委託人必須將第一個
流程（委託人擁有的流程）進入委託子流程
樹。
CGROUPS版本2螺紋模式 top
在cgroups v2施加的限制中不存在
cgroups v1如下：
* 沒有線程粒度控制：進程的所有線程
必須在同一cgroup中。
* 沒有內部進程：cgroup不能都具有成員進程
在子cgroup上行使控制權。
由於缺少這些限制，因此添加了這兩個限制
限制已導致cgroups v1中的問題。特別是
cgroups v1允許cgroup線程級粒度的能力
對於某些控制器，成員資格沒有任何意義。（一個明顯的例子
是內存控制器：由於線程共享一個地址空間，因此它
在不同的內存 cgroup中拆分線程是沒有意義的。）
儘管cgroups v2中有最初的設計決策，但仍有
某些控制器（尤其是cpu控制器）的用例用於
哪種線程級控制粒度是有意義和有用的。
爲了適應這樣的使用情況下，Linux的4.14增加線程模式爲
cgroups v2。
線程模式允許以下操作：
*創建線程子樹，其中一個線程
進程可能分散在樹內的cgroup中。（一個線程
子樹可能包含多個多線程進程。）
* 可以分佈的線程控制器的概念
線程子樹中cgroup上的資源。
*放寬“無內部流程規則”，以便在
一個線程子樹，一個cgroup既可以包含成員線程，又可以包含
對子cgroup進行資源控制。
添加了線程模式後，每個非根cgroup現在都包含一個公開的
新文件cgroup.type，在某些情況下可以是
用於更改cgroup的“類型”。此文件包含以下內容之一
以下類型值：
域這是一個正常的v2 cgroup，可提供過程粒度
控制。如果某個進程是該cgroup的成員，則所有
進程的線程（根據定義）在同一cgroup中。
這是默認的cgroup類型，並提供相同的
爲初始cgroup中的cgroup提供的行爲
v2實施。
螺紋的
此cgroup是線程子樹的成員。線程可以是
添加到此cgroup中，並且可以爲
cgroup。
域線程化
這是一個域cgroup，用作線程的根
子樹。這種cgroup類型也稱爲“線程根”。
域無效
這是線程子樹中的一個cgroup
“無效”狀態。進程無法添加到cgroup，並且
無法爲cgroup啓用控制器。唯一的事情
可以使用此cgroup進行操作（而不是刪除它）是
將其轉換爲一個線程寫入字符串cgroup的
“線程”的cgroup.type文件。
在此期間，這種“臨時”類型存在的理由
創建線程子樹（而不是內核）
只需立即在線程下轉換所有cgroup線程
類型的根）是爲了將來可能
線程模式模型的擴展
線程與域控制器
通過添加線程模式，cgroups v2現在可以區分兩個
資源控制器的類型：
* 線程控制器：這些控制器支持線程粒度
用於資源控制，並且可以在線程子樹中啓用，
結果是相應的控制器接口文件
出現在線程子樹的cgroup中。截至Linux
在4.19中，以下控制器是線程化的：cpu，perf_event和
pids。
* 域控制器：這些控制器僅支持進程
資源控制的粒度。從一個角度
域控制器，一個進程的所有線程總是在同一個
cgroup。無法在線程內部啓用域控制器
子樹。
創建一個線程子樹
有兩種途徑可導致創建線程
子樹。第一條途徑如下：
1.我們將字符串“ threaded”寫入當前具有域類型cgroup y / z的cgroup.type文件
。這具有以下
效果：
* cgroup y / z的類型變爲線程化。
*父cgroup的類型y成爲域線程。的
父cgroup是線程子樹的根（也稱爲
“線程根”）。
* y下的所有其他cgroup 尚未被
線程化（因爲它們在已經存在的線程內）
新線程根目錄下的子樹）轉換爲type
域無效。隨後在y下創建的cgroup 將
也有類型域無效。
2.我們將字符串“ threaded”寫入y
下的每個域無效 cgroup ，以便將它們轉換爲threaded類型。
作爲此步驟的結果，線程根下的所有線程
現在具有線程類型，並且線程子樹現在已完全
可用的。要求爲每個線程寫“線程化”
cgroups有點麻煩，但可以考慮將來的發展
線程模式模型的擴展。
創建線程子樹的第二種方法如下：
1.在現有的cgroup z中，當前的cgroup 類型爲domain，我們
（1）啓用一個或多個線程控制器，以及（2）進行處理z
的成員。（這兩個步驟可以按任何順序完成。）
這具有以下後果：
* z的類型成爲域線程。
*所有的後裔cgroup中的X是不是已經是
類型線程轉換爲類型域無效。
2.和以前一樣，我們通過編寫
字符串“線程化”到y下每個域無效的 cgroup ，
爲了將它們轉換爲threaded類型。
以上創建線程的途徑的後果之一
子樹是線程根cgroup只能是父節點
線程化（且域無效）的cgroup。線程根cgroup
不能是域 cgroup 的父級，而線程化 cgroup不能
有一個域 cgroup 的兄弟姐妹。
使用線程子樹
在線程子樹中，可以在以下位置啓用線程控制器
每個類型更改爲線程的子組; 這樣做後
相應的控制器接口文件出現在子級中
該cgroup的。
通過將進程的PID寫入以下內容，可以將其移動到線程子樹中：樹內cgroup之一中
的cgroup.procs文件。這個
具有使所有線程成爲該進程的成員的作用
相應的cgroup並使該進程成爲
線程子樹。然後可以傳播進程的線程
通過寫入線程子樹的線程ID來遍歷線程子樹（請參閱
gettid（2））到內部不同cgroup中的cgroup.threads文件
子樹。進程的線程必須全部駐留在同一線程中
線程子樹。
與寫入cgroup.procs一樣，某些包含規則在以下情況下適用
寫入cgroup.threads文件：
*作者必須對cgroup.threads文件具有寫權限
在目標cgroup中。
*作者必須對以下位置的cgroup.procs文件具有寫許可權：
源和目標cgroup的共同祖先。（在
在某些情況下，共同祖先可能是來源或目的地
cgroup本身。）
*源cgroup和目標cgroup必須在同一線程中
子樹。（在線程子樹之外，嘗試移動線程
通過將其線程ID寫入另一個域 cgroup中的cgroup.threads文件
失敗，錯誤爲EOPNOTSUPP。）
該cgroup.threads文件存在於每個cgroup中（包括域
cgroups）並可以讀取以發現線程組
在cgroup中。在以下情況下獲得的一組線程ID
不保證閱讀此文件是有序的或免費的
重複。
該cgroup.procs在螺紋根文件顯示所有的PID
線程子樹成員的進程。該cgroup.procs
子樹中其他cgroup中的文件不可讀。
無法在線程子樹中啓用域控制器。沒有
控制器接口文件顯示在
螺紋根。從域控制器的角度來看，
線程子樹是不可見的：內部的一個多線程進程
線程子樹在域控制器中顯示爲一個進程，
駐留在線程根cgroup中。
在線程子樹中，“無內部進程”規則不
適用：一個cgroup可以同時包含成員進程（或線程）和
在兒童cgroup上行使控制權。
寫入cgroup.type和創建線程子樹
的規則寫入cgroup.type文件時，有許多規則適用：
*只能寫入字符串“ threaded”。換句話說，
唯一可能的顯式轉換是將域
cgroup 轉換爲threaded類型。
*編寫“線程”的效果取決於cgroup.type中的當前值
，如下所示：
· 域或域線程化：開始創建線程
通過第一個子樹（其根是此cgroup的父樹）
上述途徑；
· 域無效：轉換此cgroup（位於線程內部）
子樹）到可用（即線程化）狀態；
· 線程化：無效（“無操作”）。
* 如果父級的類型是domain invalid，則無法寫入cgroup.type文件
。換句話說，線程子樹的cgroup
必須以自頂向下的方式轉換爲線程狀態。
爲了滿足以下條件，還必須滿足一些約束條件：
創建一個以cgroup x爲根的線程子樹：
* x的後代cgroup中沒有成員進程。
（cgroup x本身可以具有成員進程。）
*不能在x的cgroup.subtree_control中啓用域控制器
文件。
如果違反了上述任何約束，則嘗試寫
“線程化”到cgroup.type文件失敗，並顯示錯誤ENOTSUP。
“域線程化” cgroup類型
根據上述途徑，cgroup的類型可以在以下兩種情況下，請
更改爲域線程：
*字符串“ threaded”被寫入子cgroup。
*在cgroup和進程內部啓用了線程控制器
成爲cgroup的成員。
如果域線程 cgroup x可以恢復爲類型域，
上述條件不再成立-也就是說，如果所有線程子代x的
cgroup 被刪除，並且x不再具有線程關係
控制器已啓用或不再具有成員進程。
當域線程化的 cgroup x恢復爲類型domain時：
* x的所有域無效後代不在較低級別
線程化的子樹還原爲類型domain。
*任何較低級別的線程子樹中的根cgroup都還原爲
類型域線程化。
根cgroup的例外
v2層次結構的根cgroup受到特殊對待：它可以
是域和線程 cgroup 的父級。如果將字符串
“ threaded”寫入子項之一的cgroup.type文件中
根cgroup的
*該cgroup的類型變爲線程化。
*不屬於該cgroup的任何後代的類型
低級線程子樹更改爲域invalid。
請注意，在這種情況下，沒有cgroup的類型變爲domain
threaded。（通常，根cgroup可被視爲
類型更改爲threaded的cgroup的線程根。）
對根cgroup的這種特殊處理的目的是允許
使用cpu控制器的線程cgroup 放置爲
在層次結構中儘可能地高，以最小化（小）成本
遍歷cgroup層次結構的過程。
cgroups v2“ cpu”控制器和實時線程
從Linux 4.19開始，cgroups v2 cpu控制器不支持
控制實時線程（特別是在任何
政策的SCHED_FIFO，SCHED_RR，描述SCHED_DEADLINE ; 參見
sched（7））。因此，可以在根目錄中啓用cpu控制器
僅當所有實時線程都在根cgroup中時，才使用cgroup。（如果
有實時線程在非根的cgroup，則寫（2）的
字符串“ + cpu”到cgroup.subtree_control文件失敗，並顯示錯誤
EINVAL。）
在某些系統上，systemd（1）將某些實時線程放置在
v2層次結構中的非根cgroup。在此類系統上，這些線程
必須先將其移至根cgroup，然後才能使用cpu控制器
被啓用。
mount（2） 可能發生以下錯誤：
EBUSY 嘗試掛載指定的cgroup版本1文件系統
無論是名稱=選項（安裝一個名爲層次），也不是
控制器名稱（或全部）。
通過fork（2）創建的子進程繼承其父級的cgroup
會員資格。進程的cgroup成員資格保留在
execve（2）。
該clone3（2） CLONE_INTO_CGROUP標誌可用於創建一個子
進程開始於與版本2 cgroup不同的版本
父進程。
/ proc文件
/ proc / cgroups（從Linux 2.6.24開始）
該文件包含有關以下控制器的信息：
編譯到內核中。這個內容的一個例子
文件（經過重新格式化以提高可讀性）如下：
#subsys_name層次結構num_cgroups已啓用
cpuset 4 1 1
CPU 8 1 1
cpuacct 8 1 1
blkio 6 1 1
內存3 1 1
設備10 84 1
冷凍櫃7 1 1
net_cls 9 1 1
perf_event 5 1 1
net_prio 9 1 1
巨大的磅0 1 0
pids 2 1 1
該文件中的字段從左到右爲：
1.控制器的名稱。
2.此操作所在的cgroup層次結構的唯一ID
拖釣器已安裝。如果有多個cgroup v1控制器
綁定到相同的層次結構，那麼每個將顯示相同
此字段中的層次結構ID。該字段中的值將
如果爲0，則爲0
a）控制器未安裝在cgroups v1層級上
chy
b）控制器綁定到cgroups v2單個uni-
嚴格的等級制度；要麼
c）控制器被禁用（見下文）。
3.在此層次結構中使用此控件的控件組數
控制器。
4.如果此控制器是，則此字段包含值1。
啓用，或者0，如果它已被禁用（通過cgroup_dis-
能夠內核命令行啓動參數）。
/ proc / [pid] / cgroup（從Linux 2.6.24開始）
該文件描述了處理過程所涉及的控制組
相應的PID屬於。顯示的信息不同
cgroups版本1和版本2層次結構的fers。
對於該進程所屬的每個cgroup層次結構，
有一個條目包含三個冒號分隔的字段：
層次結構ID：控制器列表：cgroup-path
例如：
5：cpuacct，cpu，cpuset：/守護程序
冒號分隔的字段是從左到右：
1.對於cgroups版本1層次結構，此字段包含一個
可以與層級匹配的唯一層次結構ID號
chy ID在/ proc / cgroups中。對於cgroups 2 hierar‐
chy，此字段包含值0。
2.對於cgroups版本1層次結構，此字段包含一個
以逗號分隔的綁定到層次結構的控制器列表
拱形。對於cgroups版本2層次結構，此字段爲
空的。
3.此字段包含以下位置的控制組的路徑名
進程所屬的層次結構。這個路徑名
相對於層次結構的安裝點。
/ sys / kernel / cgroup文件
/ sys / kernel / cgroup / delegate（從Linux 4.15開始）
此文件導出cgroups v2文件的列表（每個
可轉讓的（即其所有權應爲
更改爲代表的用戶ID）。將來，
可代理文件集可能會更改或增長，並且此文件
爲內核提供了一種通知用戶空間應用程序的方法
必須委派哪些文件。在Linux 4.15上，
檢查此文件時看到以下內容：
$ cat / sys / kernel / cgroup / delegate
cgroup.procs
cgroup.subtree_control
cgroup.threads
/ sys / kernel / cgroup / features（從Linux 4.15開始）
隨着時間的流逝，由以下人員提供的一組cgroups v2功能
內核可能會更改或增長，或者某些功能可能無法更改
默認情況下啓用。該文件爲用戶空間提供了一種方法
應用程序以發現正在運行的內核具有哪些功能
端口並已啓用。每行列出一項功能：
$ cat / sys / kernel / cgroup / features
nsdelegate
memory_localevents
可以顯示在此文件中的條目是：
memory_localevents（從Linux 5.2開始）
內核支持memory_localevents掛載
選項。
nsdelegate（從Linux 4.15開始）
內核支持nsdelegate掛載選項。
另請參閱 頂部
prlimit（1），systemd（1），systemd-cgls（1），systemd-cgtop（1），clone（2），
ioprio_set（2），perf_event_open（2），setrlimit（2），
cgroup_namespaces（7），cpuset （7），namespaces（7），sched（7），
user_namespaces（7）
內核源文件Documentation / admin-guide / cgroup-v2.rst。
COLOPHON 上衣
該頁面是Linux 手冊頁項目5.07版的一部分。一個
項目說明，有關報告錯誤的信息以及
該頁面的最新版本，可以在以下位置找到
https://www.kernel.org/doc/man-pages/。
Linux 2020年4月11日CGROUPS（7）
