Commit | Line | Data |
---|---|---|
e5ba9ea6 KK |
1 | .. _cgroup-v2: |
2 | ||
633b11be | 3 | ================ |
6c292092 | 4 | Control Group v2 |
633b11be | 5 | ================ |
6c292092 | 6 | |
633b11be MCC |
7 | :Date: October, 2015 |
8 | :Author: Tejun Heo <tj@kernel.org> | |
6c292092 TH |
9 | |
10 | This is the authoritative documentation on the design, interface and | |
11 | conventions of cgroup v2. It describes all userland-visible aspects | |
12 | of cgroup including core and specific controller behaviors. All | |
13 | future changes must be reflected in this document. Documentation for | |
373e8ffa | 14 | v1 is available under :ref:`Documentation/admin-guide/cgroup-v1/index.rst <cgroup-v1>`. |
6c292092 | 15 | |
633b11be MCC |
16 | .. CONTENTS |
17 | ||
18 | 1. Introduction | |
19 | 1-1. Terminology | |
20 | 1-2. What is cgroup? | |
21 | 2. Basic Operations | |
22 | 2-1. Mounting | |
8cfd8147 TH |
23 | 2-2. Organizing Processes and Threads |
24 | 2-2-1. Processes | |
25 | 2-2-2. Threads | |
633b11be MCC |
26 | 2-3. [Un]populated Notification |
27 | 2-4. Controlling Controllers | |
28 | 2-4-1. Enabling and Disabling | |
29 | 2-4-2. Top-down Constraint | |
30 | 2-4-3. No Internal Process Constraint | |
31 | 2-5. Delegation | |
32 | 2-5-1. Model of Delegation | |
33 | 2-5-2. Delegation Containment | |
34 | 2-6. Guidelines | |
35 | 2-6-1. Organize Once and Control | |
36 | 2-6-2. Avoid Name Collisions | |
37 | 3. Resource Distribution Models | |
38 | 3-1. Weights | |
39 | 3-2. Limits | |
40 | 3-3. Protections | |
41 | 3-4. Allocations | |
42 | 4. Interface Files | |
43 | 4-1. Format | |
44 | 4-2. Conventions | |
45 | 4-3. Core Interface Files | |
46 | 5. Controllers | |
47 | 5-1. CPU | |
48 | 5-1-1. CPU Interface Files | |
49 | 5-2. Memory | |
50 | 5-2-1. Memory Interface Files | |
51 | 5-2-2. Usage Guidelines | |
52 | 5-2-3. Memory Ownership | |
53 | 5-3. IO | |
54 | 5-3-1. IO Interface Files | |
55 | 5-3-2. Writeback | |
b351f0c7 JB |
56 | 5-3-3. IO Latency |
57 | 5-3-3-1. How IO Latency Throttling Works | |
58 | 5-3-3-2. IO Latency Interface Files | |
556910e3 | 59 | 5-3-4. IO Priority |
633b11be MCC |
60 | 5-4. PID |
61 | 5-4-1. PID Interface Files | |
4ec22e9c WL |
62 | 5-5. Cpuset |
63 | 5.5-1. Cpuset Interface Files | |
64 | 5-6. Device | |
65 | 5-7. RDMA | |
66 | 5-7-1. RDMA Interface Files | |
faced7e0 GS |
67 | 5-8. HugeTLB |
68 | 5.8-1. HugeTLB Interface Files | |
25259fc9 VS |
69 | 5-9. Misc |
70 | 5.9-1 Miscellaneous cgroup Interface Files | |
71 | 5.9-2 Migration and Ownership | |
72 | 5-10. Others | |
73 | 5-10-1. perf_event | |
c4e0842b MS |
74 | 5-N. Non-normative information |
75 | 5-N-1. CPU controller root cgroup process behaviour | |
76 | 5-N-2. IO controller root cgroup process behaviour | |
633b11be MCC |
77 | 6. Namespace |
78 | 6-1. Basics | |
79 | 6-2. The Root and Views | |
80 | 6-3. Migration and setns(2) | |
81 | 6-4. Interaction with Other Namespaces | |
82 | P. Information on Kernel Programming | |
83 | P-1. Filesystem Support for Writeback | |
84 | D. Deprecated v1 Core Features | |
85 | R. Issues with v1 and Rationales for v2 | |
86 | R-1. Multiple Hierarchies | |
87 | R-2. Thread Granularity | |
88 | R-3. Competition Between Inner Nodes and Threads | |
89 | R-4. Other Interface Issues | |
90 | R-5. Controller Issues and Remedies | |
91 | R-5-1. Memory | |
92 | ||
93 | ||
94 | Introduction | |
95 | ============ | |
96 | ||
97 | Terminology | |
98 | ----------- | |
6c292092 TH |
99 | |
100 | "cgroup" stands for "control group" and is never capitalized. The | |
101 | singular form is used to designate the whole feature and also as a | |
102 | qualifier as in "cgroup controllers". When explicitly referring to | |
103 | multiple individual control groups, the plural form "cgroups" is used. | |
104 | ||
105 | ||
633b11be MCC |
106 | What is cgroup? |
107 | --------------- | |
6c292092 TH |
108 | |
109 | cgroup is a mechanism to organize processes hierarchically and | |
110 | distribute system resources along the hierarchy in a controlled and | |
111 | configurable manner. | |
112 | ||
113 | cgroup is largely composed of two parts - the core and controllers. | |
114 | cgroup core is primarily responsible for hierarchically organizing | |
115 | processes. A cgroup controller is usually responsible for | |
116 | distributing a specific type of system resource along the hierarchy | |
117 | although there are utility controllers which serve purposes other than | |
118 | resource distribution. | |
119 | ||
120 | cgroups form a tree structure and every process in the system belongs | |
121 | to one and only one cgroup. All threads of a process belong to the | |
122 | same cgroup. On creation, all processes are put in the cgroup that | |
123 | the parent process belongs to at the time. A process can be migrated | |
124 | to another cgroup. Migration of a process doesn't affect already | |
125 | existing descendant processes. | |
126 | ||
127 | Following certain structural constraints, controllers may be enabled or | |
128 | disabled selectively on a cgroup. All controller behaviors are | |
129 | hierarchical - if a controller is enabled on a cgroup, it affects all | |
130 | processes which belong to the cgroups consisting the inclusive | |
131 | sub-hierarchy of the cgroup. When a controller is enabled on a nested | |
132 | cgroup, it always restricts the resource distribution further. The | |
133 | restrictions set closer to the root in the hierarchy can not be | |
134 | overridden from further away. | |
135 | ||
136 | ||
633b11be MCC |
137 | Basic Operations |
138 | ================ | |
6c292092 | 139 | |
633b11be MCC |
140 | Mounting |
141 | -------- | |
6c292092 TH |
142 | |
143 | Unlike v1, cgroup v2 has only single hierarchy. The cgroup v2 | |
633b11be | 144 | hierarchy can be mounted with the following mount command:: |
6c292092 TH |
145 | |
146 | # mount -t cgroup2 none $MOUNT_POINT | |
147 | ||
148 | cgroup2 filesystem has the magic number 0x63677270 ("cgrp"). All | |
149 | controllers which support v2 and are not bound to a v1 hierarchy are | |
150 | automatically bound to the v2 hierarchy and show up at the root. | |
151 | Controllers which are not in active use in the v2 hierarchy can be | |
152 | bound to other hierarchies. This allows mixing v2 hierarchy with the | |
153 | legacy v1 multiple hierarchies in a fully backward compatible way. | |
154 | ||
155 | A controller can be moved across hierarchies only after the controller | |
156 | is no longer referenced in its current hierarchy. Because per-cgroup | |
157 | controller states are destroyed asynchronously and controllers may | |
158 | have lingering references, a controller may not show up immediately on | |
159 | the v2 hierarchy after the final umount of the previous hierarchy. | |
160 | Similarly, a controller should be fully disabled to be moved out of | |
161 | the unified hierarchy and it may take some time for the disabled | |
162 | controller to become available for other hierarchies; furthermore, due | |
163 | to inter-controller dependencies, other controllers may need to be | |
164 | disabled too. | |
165 | ||
166 | While useful for development and manual configurations, moving | |
167 | controllers dynamically between the v2 and other hierarchies is | |
168 | strongly discouraged for production use. It is recommended to decide | |
169 | the hierarchies and controller associations before starting using the | |
170 | controllers after system boot. | |
171 | ||
1619b6d4 JW |
172 | During transition to v2, system management software might still |
173 | automount the v1 cgroup filesystem and so hijack all controllers | |
174 | during boot, before manual intervention is possible. To make testing | |
175 | and experimenting easier, the kernel parameter cgroup_no_v1= allows | |
176 | disabling controllers in v1 and make them always available in v2. | |
177 | ||
5136f636 TH |
178 | cgroup v2 currently supports the following mount options. |
179 | ||
c808f463 | 180 | nsdelegate |
5136f636 TH |
181 | Consider cgroup namespaces as delegation boundaries. This |
182 | option is system wide and can only be set on mount or modified | |
183 | through remount from the init namespace. The mount option is | |
184 | ignored on non-init namespace mounts. Please refer to the | |
185 | Delegation section for details. | |
186 | ||
c808f463 | 187 | favordynmods |
6a010a49 TH |
188 | Reduce the latencies of dynamic cgroup modifications such as |
189 | task migrations and controller on/offs at the cost of making | |
190 | hot path operations such as forks and exits more expensive. | |
191 | The static usage pattern of creating a cgroup, enabling | |
192 | controllers, and then seeding it with CLONE_INTO_CGROUP is | |
193 | not affected by this option. | |
194 | ||
c808f463 | 195 | memory_localevents |
9852ae3f CD |
196 | Only populate memory.events with data for the current cgroup, |
197 | and not any subtrees. This is legacy behaviour, the default | |
198 | behaviour without this option is to include subtree counts. | |
199 | This option is system wide and can only be set on mount or | |
200 | modified through remount from the init namespace. The mount | |
201 | option is ignored on non-init namespace mounts. | |
202 | ||
c808f463 | 203 | memory_recursiveprot |
8a931f80 JW |
204 | Recursively apply memory.min and memory.low protection to |
205 | entire subtrees, without requiring explicit downward | |
206 | propagation into leaf cgroups. This allows protecting entire | |
207 | subtrees from one another, while retaining free competition | |
208 | within those subtrees. This should have been the default | |
209 | behavior but is a mount-option to avoid regressing setups | |
210 | relying on the original semantics (e.g. specifying bogusly | |
211 | high 'bypass' protection values at higher tree levels). | |
212 | ||
6c292092 | 213 | |
8cfd8147 TH |
214 | Organizing Processes and Threads |
215 | -------------------------------- | |
216 | ||
217 | Processes | |
218 | ~~~~~~~~~ | |
6c292092 TH |
219 | |
220 | Initially, only the root cgroup exists to which all processes belong. | |
633b11be | 221 | A child cgroup can be created by creating a sub-directory:: |
6c292092 TH |
222 | |
223 | # mkdir $CGROUP_NAME | |
224 | ||
225 | A given cgroup may have multiple child cgroups forming a tree | |
226 | structure. Each cgroup has a read-writable interface file | |
227 | "cgroup.procs". When read, it lists the PIDs of all processes which | |
228 | belong to the cgroup one-per-line. The PIDs are not ordered and the | |
229 | same PID may show up more than once if the process got moved to | |
230 | another cgroup and then back or the PID got recycled while reading. | |
231 | ||
232 | A process can be migrated into a cgroup by writing its PID to the | |
233 | target cgroup's "cgroup.procs" file. Only one process can be migrated | |
234 | on a single write(2) call. If a process is composed of multiple | |
235 | threads, writing the PID of any thread migrates all threads of the | |
236 | process. | |
237 | ||
238 | When a process forks a child process, the new process is born into the | |
239 | cgroup that the forking process belongs to at the time of the | |
240 | operation. After exit, a process stays associated with the cgroup | |
241 | that it belonged to at the time of exit until it's reaped; however, a | |
242 | zombie process does not appear in "cgroup.procs" and thus can't be | |
243 | moved to another cgroup. | |
244 | ||
245 | A cgroup which doesn't have any children or live processes can be | |
246 | destroyed by removing the directory. Note that a cgroup which doesn't | |
247 | have any children and is associated only with zombie processes is | |
633b11be | 248 | considered empty and can be removed:: |
6c292092 TH |
249 | |
250 | # rmdir $CGROUP_NAME | |
251 | ||
252 | "/proc/$PID/cgroup" lists a process's cgroup membership. If legacy | |
253 | cgroup is in use in the system, this file may contain multiple lines, | |
254 | one for each hierarchy. The entry for cgroup v2 is always in the | |
633b11be | 255 | format "0::$PATH":: |
6c292092 TH |
256 | |
257 | # cat /proc/842/cgroup | |
258 | ... | |
259 | 0::/test-cgroup/test-cgroup-nested | |
260 | ||
261 | If the process becomes a zombie and the cgroup it was associated with | |
633b11be | 262 | is removed subsequently, " (deleted)" is appended to the path:: |
6c292092 TH |
263 | |
264 | # cat /proc/842/cgroup | |
265 | ... | |
266 | 0::/test-cgroup/test-cgroup-nested (deleted) | |
267 | ||
268 | ||
8cfd8147 TH |
269 | Threads |
270 | ~~~~~~~ | |
271 | ||
272 | cgroup v2 supports thread granularity for a subset of controllers to | |
273 | support use cases requiring hierarchical resource distribution across | |
274 | the threads of a group of processes. By default, all threads of a | |
275 | process belong to the same cgroup, which also serves as the resource | |
276 | domain to host resource consumptions which are not specific to a | |
277 | process or thread. The thread mode allows threads to be spread across | |
278 | a subtree while still maintaining the common resource domain for them. | |
279 | ||
280 | Controllers which support thread mode are called threaded controllers. | |
281 | The ones which don't are called domain controllers. | |
282 | ||
283 | Marking a cgroup threaded makes it join the resource domain of its | |
284 | parent as a threaded cgroup. The parent may be another threaded | |
285 | cgroup whose resource domain is further up in the hierarchy. The root | |
286 | of a threaded subtree, that is, the nearest ancestor which is not | |
287 | threaded, is called threaded domain or thread root interchangeably and | |
288 | serves as the resource domain for the entire subtree. | |
289 | ||
290 | Inside a threaded subtree, threads of a process can be put in | |
291 | different cgroups and are not subject to the no internal process | |
292 | constraint - threaded controllers can be enabled on non-leaf cgroups | |
293 | whether they have threads in them or not. | |
294 | ||
295 | As the threaded domain cgroup hosts all the domain resource | |
296 | consumptions of the subtree, it is considered to have internal | |
297 | resource consumptions whether there are processes in it or not and | |
298 | can't have populated child cgroups which aren't threaded. Because the | |
299 | root cgroup is not subject to no internal process constraint, it can | |
300 | serve both as a threaded domain and a parent to domain cgroups. | |
301 | ||
302 | The current operation mode or type of the cgroup is shown in the | |
303 | "cgroup.type" file which indicates whether the cgroup is a normal | |
304 | domain, a domain which is serving as the domain of a threaded subtree, | |
305 | or a threaded cgroup. | |
306 | ||
307 | On creation, a cgroup is always a domain cgroup and can be made | |
308 | threaded by writing "threaded" to the "cgroup.type" file. The | |
309 | operation is single direction:: | |
310 | ||
311 | # echo threaded > cgroup.type | |
312 | ||
313 | Once threaded, the cgroup can't be made a domain again. To enable the | |
314 | thread mode, the following conditions must be met. | |
315 | ||
316 | - As the cgroup will join the parent's resource domain. The parent | |
317 | must either be a valid (threaded) domain or a threaded cgroup. | |
318 | ||
918a8c2c TH |
319 | - When the parent is an unthreaded domain, it must not have any domain |
320 | controllers enabled or populated domain children. The root is | |
321 | exempt from this requirement. | |
8cfd8147 TH |
322 | |
323 | Topology-wise, a cgroup can be in an invalid state. Please consider | |
2877cbe6 | 324 | the following topology:: |
8cfd8147 TH |
325 | |
326 | A (threaded domain) - B (threaded) - C (domain, just created) | |
327 | ||
328 | C is created as a domain but isn't connected to a parent which can | |
329 | host child domains. C can't be used until it is turned into a | |
330 | threaded cgroup. "cgroup.type" file will report "domain (invalid)" in | |
331 | these cases. Operations which fail due to invalid topology use | |
332 | EOPNOTSUPP as the errno. | |
333 | ||
334 | A domain cgroup is turned into a threaded domain when one of its child | |
335 | cgroup becomes threaded or threaded controllers are enabled in the | |
336 | "cgroup.subtree_control" file while there are processes in the cgroup. | |
337 | A threaded domain reverts to a normal domain when the conditions | |
338 | clear. | |
339 | ||
340 | When read, "cgroup.threads" contains the list of the thread IDs of all | |
341 | threads in the cgroup. Except that the operations are per-thread | |
342 | instead of per-process, "cgroup.threads" has the same format and | |
343 | behaves the same way as "cgroup.procs". While "cgroup.threads" can be | |
344 | written to in any cgroup, as it can only move threads inside the same | |
345 | threaded domain, its operations are confined inside each threaded | |
346 | subtree. | |
347 | ||
348 | The threaded domain cgroup serves as the resource domain for the whole | |
349 | subtree, and, while the threads can be scattered across the subtree, | |
350 | all the processes are considered to be in the threaded domain cgroup. | |
351 | "cgroup.procs" in a threaded domain cgroup contains the PIDs of all | |
352 | processes in the subtree and is not readable in the subtree proper. | |
353 | However, "cgroup.procs" can be written to from anywhere in the subtree | |
354 | to migrate all threads of the matching process to the cgroup. | |
355 | ||
356 | Only threaded controllers can be enabled in a threaded subtree. When | |
357 | a threaded controller is enabled inside a threaded subtree, it only | |
358 | accounts for and controls resource consumptions associated with the | |
359 | threads in the cgroup and its descendants. All consumptions which | |
360 | aren't tied to a specific thread belong to the threaded domain cgroup. | |
361 | ||
362 | Because a threaded subtree is exempt from no internal process | |
363 | constraint, a threaded controller must be able to handle competition | |
364 | between threads in a non-leaf cgroup and its child cgroups. Each | |
365 | threaded controller defines how such competitions are handled. | |
366 | ||
367 | ||
633b11be MCC |
368 | [Un]populated Notification |
369 | -------------------------- | |
6c292092 TH |
370 | |
371 | Each non-root cgroup has a "cgroup.events" file which contains | |
372 | "populated" field indicating whether the cgroup's sub-hierarchy has | |
373 | live processes in it. Its value is 0 if there is no live process in | |
374 | the cgroup and its descendants; otherwise, 1. poll and [id]notify | |
375 | events are triggered when the value changes. This can be used, for | |
376 | example, to start a clean-up operation after all processes of a given | |
377 | sub-hierarchy have exited. The populated state updates and | |
378 | notifications are recursive. Consider the following sub-hierarchy | |
379 | where the numbers in the parentheses represent the numbers of processes | |
633b11be | 380 | in each cgroup:: |
6c292092 TH |
381 | |
382 | A(4) - B(0) - C(1) | |
383 | \ D(0) | |
384 | ||
385 | A, B and C's "populated" fields would be 1 while D's 0. After the one | |
386 | process in C exits, B and C's "populated" fields would flip to "0" and | |
387 | file modified events will be generated on the "cgroup.events" files of | |
388 | both cgroups. | |
389 | ||
390 | ||
633b11be MCC |
391 | Controlling Controllers |
392 | ----------------------- | |
6c292092 | 393 | |
633b11be MCC |
394 | Enabling and Disabling |
395 | ~~~~~~~~~~~~~~~~~~~~~~ | |
6c292092 TH |
396 | |
397 | Each cgroup has a "cgroup.controllers" file which lists all | |
633b11be | 398 | controllers available for the cgroup to enable:: |
6c292092 TH |
399 | |
400 | # cat cgroup.controllers | |
401 | cpu io memory | |
402 | ||
403 | No controller is enabled by default. Controllers can be enabled and | |
633b11be | 404 | disabled by writing to the "cgroup.subtree_control" file:: |
6c292092 TH |
405 | |
406 | # echo "+cpu +memory -io" > cgroup.subtree_control | |
407 | ||
408 | Only controllers which are listed in "cgroup.controllers" can be | |
409 | enabled. When multiple operations are specified as above, either they | |
410 | all succeed or fail. If multiple operations on the same controller | |
411 | are specified, the last one is effective. | |
412 | ||
413 | Enabling a controller in a cgroup indicates that the distribution of | |
414 | the target resource across its immediate children will be controlled. | |
415 | Consider the following sub-hierarchy. The enabled controllers are | |
633b11be | 416 | listed in parentheses:: |
6c292092 TH |
417 | |
418 | A(cpu,memory) - B(memory) - C() | |
419 | \ D() | |
420 | ||
421 | As A has "cpu" and "memory" enabled, A will control the distribution | |
422 | of CPU cycles and memory to its children, in this case, B. As B has | |
423 | "memory" enabled but not "CPU", C and D will compete freely on CPU | |
424 | cycles but their division of memory available to B will be controlled. | |
425 | ||
426 | As a controller regulates the distribution of the target resource to | |
427 | the cgroup's children, enabling it creates the controller's interface | |
428 | files in the child cgroups. In the above example, enabling "cpu" on B | |
429 | would create the "cpu." prefixed controller interface files in C and | |
430 | D. Likewise, disabling "memory" from B would remove the "memory." | |
431 | prefixed controller interface files from C and D. This means that the | |
432 | controller interface files - anything which doesn't start with | |
433 | "cgroup." are owned by the parent rather than the cgroup itself. | |
434 | ||
435 | ||
633b11be MCC |
436 | Top-down Constraint |
437 | ~~~~~~~~~~~~~~~~~~~ | |
6c292092 TH |
438 | |
439 | Resources are distributed top-down and a cgroup can further distribute | |
440 | a resource only if the resource has been distributed to it from the | |
441 | parent. This means that all non-root "cgroup.subtree_control" files | |
442 | can only contain controllers which are enabled in the parent's | |
443 | "cgroup.subtree_control" file. A controller can be enabled only if | |
444 | the parent has the controller enabled and a controller can't be | |
445 | disabled if one or more children have it enabled. | |
446 | ||
447 | ||
633b11be MCC |
448 | No Internal Process Constraint |
449 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
6c292092 | 450 | |
8cfd8147 TH |
451 | Non-root cgroups can distribute domain resources to their children |
452 | only when they don't have any processes of their own. In other words, | |
453 | only domain cgroups which don't contain any processes can have domain | |
454 | controllers enabled in their "cgroup.subtree_control" files. | |
6c292092 | 455 | |
8cfd8147 TH |
456 | This guarantees that, when a domain controller is looking at the part |
457 | of the hierarchy which has it enabled, processes are always only on | |
458 | the leaves. This rules out situations where child cgroups compete | |
459 | against internal processes of the parent. | |
6c292092 TH |
460 | |
461 | The root cgroup is exempt from this restriction. Root contains | |
462 | processes and anonymous resource consumption which can't be associated | |
463 | with any other cgroups and requires special treatment from most | |
464 | controllers. How resource consumption in the root cgroup is governed | |
c4e0842b MS |
465 | is up to each controller (for more information on this topic please |
466 | refer to the Non-normative information section in the Controllers | |
467 | chapter). | |
6c292092 TH |
468 | |
469 | Note that the restriction doesn't get in the way if there is no | |
470 | enabled controller in the cgroup's "cgroup.subtree_control". This is | |
471 | important as otherwise it wouldn't be possible to create children of a | |
472 | populated cgroup. To control resource distribution of a cgroup, the | |
473 | cgroup must create children and transfer all its processes to the | |
474 | children before enabling controllers in its "cgroup.subtree_control" | |
475 | file. | |
476 | ||
477 | ||
633b11be MCC |
478 | Delegation |
479 | ---------- | |
6c292092 | 480 | |
633b11be MCC |
481 | Model of Delegation |
482 | ~~~~~~~~~~~~~~~~~~~ | |
6c292092 | 483 | |
5136f636 | 484 | A cgroup can be delegated in two ways. First, to a less privileged |
8cfd8147 TH |
485 | user by granting write access of the directory and its "cgroup.procs", |
486 | "cgroup.threads" and "cgroup.subtree_control" files to the user. | |
487 | Second, if the "nsdelegate" mount option is set, automatically to a | |
488 | cgroup namespace on namespace creation. | |
5136f636 TH |
489 | |
490 | Because the resource control interface files in a given directory | |
491 | control the distribution of the parent's resources, the delegatee | |
492 | shouldn't be allowed to write to them. For the first method, this is | |
493 | achieved by not granting access to these files. For the second, the | |
494 | kernel rejects writes to all files other than "cgroup.procs" and | |
495 | "cgroup.subtree_control" on a namespace root from inside the | |
496 | namespace. | |
497 | ||
498 | The end results are equivalent for both delegation types. Once | |
499 | delegated, the user can build sub-hierarchy under the directory, | |
500 | organize processes inside it as it sees fit and further distribute the | |
501 | resources it received from the parent. The limits and other settings | |
502 | of all resource controllers are hierarchical and regardless of what | |
503 | happens in the delegated sub-hierarchy, nothing can escape the | |
504 | resource restrictions imposed by the parent. | |
6c292092 TH |
505 | |
506 | Currently, cgroup doesn't impose any restrictions on the number of | |
507 | cgroups in or nesting depth of a delegated sub-hierarchy; however, | |
508 | this may be limited explicitly in the future. | |
509 | ||
510 | ||
633b11be MCC |
511 | Delegation Containment |
512 | ~~~~~~~~~~~~~~~~~~~~~~ | |
6c292092 TH |
513 | |
514 | A delegated sub-hierarchy is contained in the sense that processes | |
5136f636 TH |
515 | can't be moved into or out of the sub-hierarchy by the delegatee. |
516 | ||
517 | For delegations to a less privileged user, this is achieved by | |
518 | requiring the following conditions for a process with a non-root euid | |
519 | to migrate a target process into a cgroup by writing its PID to the | |
520 | "cgroup.procs" file. | |
6c292092 | 521 | |
6c292092 TH |
522 | - The writer must have write access to the "cgroup.procs" file. |
523 | ||
524 | - The writer must have write access to the "cgroup.procs" file of the | |
525 | common ancestor of the source and destination cgroups. | |
526 | ||
576dd464 | 527 | The above two constraints ensure that while a delegatee may migrate |
6c292092 TH |
528 | processes around freely in the delegated sub-hierarchy it can't pull |
529 | in from or push out to outside the sub-hierarchy. | |
530 | ||
531 | For an example, let's assume cgroups C0 and C1 have been delegated to | |
532 | user U0 who created C00, C01 under C0 and C10 under C1 as follows and | |
633b11be | 533 | all processes under C0 and C1 belong to U0:: |
6c292092 TH |
534 | |
535 | ~~~~~~~~~~~~~ - C0 - C00 | |
536 | ~ cgroup ~ \ C01 | |
537 | ~ hierarchy ~ | |
538 | ~~~~~~~~~~~~~ - C1 - C10 | |
539 | ||
540 | Let's also say U0 wants to write the PID of a process which is | |
541 | currently in C10 into "C00/cgroup.procs". U0 has write access to the | |
576dd464 TH |
542 | file; however, the common ancestor of the source cgroup C10 and the |
543 | destination cgroup C00 is above the points of delegation and U0 would | |
544 | not have write access to its "cgroup.procs" files and thus the write | |
545 | will be denied with -EACCES. | |
6c292092 | 546 | |
5136f636 TH |
547 | For delegations to namespaces, containment is achieved by requiring |
548 | that both the source and destination cgroups are reachable from the | |
549 | namespace of the process which is attempting the migration. If either | |
550 | is not reachable, the migration is rejected with -ENOENT. | |
551 | ||
6c292092 | 552 | |
633b11be MCC |
553 | Guidelines |
554 | ---------- | |
6c292092 | 555 | |
633b11be MCC |
556 | Organize Once and Control |
557 | ~~~~~~~~~~~~~~~~~~~~~~~~~ | |
6c292092 TH |
558 | |
559 | Migrating a process across cgroups is a relatively expensive operation | |
560 | and stateful resources such as memory are not moved together with the | |
561 | process. This is an explicit design decision as there often exist | |
562 | inherent trade-offs between migration and various hot paths in terms | |
563 | of synchronization cost. | |
564 | ||
565 | As such, migrating processes across cgroups frequently as a means to | |
566 | apply different resource restrictions is discouraged. A workload | |
567 | should be assigned to a cgroup according to the system's logical and | |
568 | resource structure once on start-up. Dynamic adjustments to resource | |
569 | distribution can be made by changing controller configuration through | |
570 | the interface files. | |
571 | ||
572 | ||
633b11be MCC |
573 | Avoid Name Collisions |
574 | ~~~~~~~~~~~~~~~~~~~~~ | |
6c292092 TH |
575 | |
576 | Interface files for a cgroup and its children cgroups occupy the same | |
577 | directory and it is possible to create children cgroups which collide | |
578 | with interface files. | |
579 | ||
580 | All cgroup core interface files are prefixed with "cgroup." and each | |
581 | controller's interface files are prefixed with the controller name and | |
582 | a dot. A controller's name is composed of lower case alphabets and | |
583 | '_'s but never begins with an '_' so it can be used as the prefix | |
584 | character for collision avoidance. Also, interface file names won't | |
585 | start or end with terms which are often used in categorizing workloads | |
586 | such as job, service, slice, unit or workload. | |
587 | ||
588 | cgroup doesn't do anything to prevent name collisions and it's the | |
589 | user's responsibility to avoid them. | |
590 | ||
591 | ||
633b11be MCC |
592 | Resource Distribution Models |
593 | ============================ | |
6c292092 TH |
594 | |
595 | cgroup controllers implement several resource distribution schemes | |
596 | depending on the resource type and expected use cases. This section | |
597 | describes major schemes in use along with their expected behaviors. | |
598 | ||
599 | ||
633b11be MCC |
600 | Weights |
601 | ------- | |
6c292092 TH |
602 | |
603 | A parent's resource is distributed by adding up the weights of all | |
604 | active children and giving each the fraction matching the ratio of its | |
605 | weight against the sum. As only children which can make use of the | |
606 | resource at the moment participate in the distribution, this is | |
607 | work-conserving. Due to the dynamic nature, this model is usually | |
608 | used for stateless resources. | |
609 | ||
610 | All weights are in the range [1, 10000] with the default at 100. This | |
611 | allows symmetric multiplicative biases in both directions at fine | |
612 | enough granularity while staying in the intuitive range. | |
613 | ||
614 | As long as the weight is in range, all configuration combinations are | |
615 | valid and there is no reason to reject configuration changes or | |
616 | process migrations. | |
617 | ||
618 | "cpu.weight" proportionally distributes CPU cycles to active children | |
619 | and is an example of this type. | |
620 | ||
621 | ||
acbee592 QY |
622 | .. _cgroupv2-limits-distributor: |
623 | ||
633b11be MCC |
624 | Limits |
625 | ------ | |
6c292092 | 626 | |
dbeb56fe | 627 | A child can only consume up to the configured amount of the resource. |
6c292092 TH |
628 | Limits can be over-committed - the sum of the limits of children can |
629 | exceed the amount of resource available to the parent. | |
630 | ||
631 | Limits are in the range [0, max] and defaults to "max", which is noop. | |
632 | ||
633 | As limits can be over-committed, all configuration combinations are | |
634 | valid and there is no reason to reject configuration changes or | |
635 | process migrations. | |
636 | ||
637 | "io.max" limits the maximum BPS and/or IOPS that a cgroup can consume | |
638 | on an IO device and is an example of this type. | |
639 | ||
acbee592 | 640 | .. _cgroupv2-protections-distributor: |
6c292092 | 641 | |
633b11be MCC |
642 | Protections |
643 | ----------- | |
6c292092 | 644 | |
dbeb56fe | 645 | A cgroup is protected up to the configured amount of the resource |
9783aa99 | 646 | as long as the usages of all its ancestors are under their |
6c292092 TH |
647 | protected levels. Protections can be hard guarantees or best effort |
648 | soft boundaries. Protections can also be over-committed in which case | |
dbeb56fe | 649 | only up to the amount available to the parent is protected among |
6c292092 TH |
650 | children. |
651 | ||
652 | Protections are in the range [0, max] and defaults to 0, which is | |
653 | noop. | |
654 | ||
655 | As protections can be over-committed, all configuration combinations | |
656 | are valid and there is no reason to reject configuration changes or | |
657 | process migrations. | |
658 | ||
659 | "memory.low" implements best-effort memory protection and is an | |
660 | example of this type. | |
661 | ||
662 | ||
633b11be MCC |
663 | Allocations |
664 | ----------- | |
6c292092 TH |
665 | |
666 | A cgroup is exclusively allocated a certain amount of a finite | |
667 | resource. Allocations can't be over-committed - the sum of the | |
668 | allocations of children can not exceed the amount of resource | |
669 | available to the parent. | |
670 | ||
671 | Allocations are in the range [0, max] and defaults to 0, which is no | |
672 | resource. | |
673 | ||
674 | As allocations can't be over-committed, some configuration | |
675 | combinations are invalid and should be rejected. Also, if the | |
676 | resource is mandatory for execution of processes, process migrations | |
677 | may be rejected. | |
678 | ||
679 | "cpu.rt.max" hard-allocates realtime slices and is an example of this | |
680 | type. | |
681 | ||
682 | ||
633b11be MCC |
683 | Interface Files |
684 | =============== | |
6c292092 | 685 | |
633b11be MCC |
686 | Format |
687 | ------ | |
6c292092 TH |
688 | |
689 | All interface files should be in one of the following formats whenever | |
633b11be | 690 | possible:: |
6c292092 TH |
691 | |
692 | New-line separated values | |
693 | (when only one value can be written at once) | |
694 | ||
695 | VAL0\n | |
696 | VAL1\n | |
697 | ... | |
698 | ||
699 | Space separated values | |
700 | (when read-only or multiple values can be written at once) | |
701 | ||
702 | VAL0 VAL1 ...\n | |
703 | ||
704 | Flat keyed | |
705 | ||
706 | KEY0 VAL0\n | |
707 | KEY1 VAL1\n | |
708 | ... | |
709 | ||
710 | Nested keyed | |
711 | ||
712 | KEY0 SUB_KEY0=VAL00 SUB_KEY1=VAL01... | |
713 | KEY1 SUB_KEY0=VAL10 SUB_KEY1=VAL11... | |
714 | ... | |
715 | ||
716 | For a writable file, the format for writing should generally match | |
717 | reading; however, controllers may allow omitting later fields or | |
718 | implement restricted shortcuts for most common use cases. | |
719 | ||
720 | For both flat and nested keyed files, only the values for a single key | |
721 | can be written at a time. For nested keyed files, the sub key pairs | |
722 | may be specified in any order and not all pairs have to be specified. | |
723 | ||
724 | ||
633b11be MCC |
725 | Conventions |
726 | ----------- | |
6c292092 TH |
727 | |
728 | - Settings for a single feature should be contained in a single file. | |
729 | ||
730 | - The root cgroup should be exempt from resource control and thus | |
936f2a70 | 731 | shouldn't have resource control interface files. |
6c292092 | 732 | |
a5e112e6 TH |
733 | - The default time unit is microseconds. If a different unit is ever |
734 | used, an explicit unit suffix must be present. | |
735 | ||
736 | - A parts-per quantity should use a percentage decimal with at least | |
737 | two digit fractional part - e.g. 13.40. | |
738 | ||
6c292092 TH |
739 | - If a controller implements weight based resource distribution, its |
740 | interface file should be named "weight" and have the range [1, | |
741 | 10000] with 100 as the default. The values are chosen to allow | |
742 | enough and symmetric bias in both directions while keeping it | |
743 | intuitive (the default is 100%). | |
744 | ||
745 | - If a controller implements an absolute resource guarantee and/or | |
746 | limit, the interface files should be named "min" and "max" | |
747 | respectively. If a controller implements best effort resource | |
748 | guarantee and/or limit, the interface files should be named "low" | |
749 | and "high" respectively. | |
750 | ||
751 | In the above four control files, the special token "max" should be | |
752 | used to represent upward infinity for both reading and writing. | |
753 | ||
754 | - If a setting has a configurable default value and keyed specific | |
755 | overrides, the default entry should be keyed with "default" and | |
756 | appear as the first entry in the file. | |
757 | ||
758 | The default value can be updated by writing either "default $VAL" or | |
759 | "$VAL". | |
760 | ||
761 | When writing to update a specific override, "default" can be used as | |
762 | the value to indicate removal of the override. Override entries | |
763 | with "default" as the value must not appear when read. | |
764 | ||
765 | For example, a setting which is keyed by major:minor device numbers | |
633b11be | 766 | with integer values may look like the following:: |
6c292092 TH |
767 | |
768 | # cat cgroup-example-interface-file | |
769 | default 150 | |
770 | 8:0 300 | |
771 | ||
633b11be | 772 | The default value can be updated by:: |
6c292092 TH |
773 | |
774 | # echo 125 > cgroup-example-interface-file | |
775 | ||
633b11be | 776 | or:: |
6c292092 TH |
777 | |
778 | # echo "default 125" > cgroup-example-interface-file | |
779 | ||
633b11be | 780 | An override can be set by:: |
6c292092 TH |
781 | |
782 | # echo "8:16 170" > cgroup-example-interface-file | |
783 | ||
633b11be | 784 | and cleared by:: |
6c292092 TH |
785 | |
786 | # echo "8:0 default" > cgroup-example-interface-file | |
787 | # cat cgroup-example-interface-file | |
788 | default 125 | |
789 | 8:16 170 | |
790 | ||
791 | - For events which are not very high frequency, an interface file | |
792 | "events" should be created which lists event key value pairs. | |
793 | Whenever a notifiable event happens, file modified event should be | |
794 | generated on the file. | |
795 | ||
796 | ||
633b11be MCC |
797 | Core Interface Files |
798 | -------------------- | |
6c292092 TH |
799 | |
800 | All cgroup core files are prefixed with "cgroup." | |
801 | ||
8cfd8147 | 802 | cgroup.type |
8cfd8147 TH |
803 | A read-write single value file which exists on non-root |
804 | cgroups. | |
805 | ||
806 | When read, it indicates the current type of the cgroup, which | |
807 | can be one of the following values. | |
808 | ||
809 | - "domain" : A normal valid domain cgroup. | |
810 | ||
811 | - "domain threaded" : A threaded domain cgroup which is | |
812 | serving as the root of a threaded subtree. | |
813 | ||
814 | - "domain invalid" : A cgroup which is in an invalid state. | |
815 | It can't be populated or have controllers enabled. It may | |
816 | be allowed to become a threaded cgroup. | |
817 | ||
818 | - "threaded" : A threaded cgroup which is a member of a | |
819 | threaded subtree. | |
820 | ||
821 | A cgroup can be turned into a threaded cgroup by writing | |
822 | "threaded" to this file. | |
823 | ||
6c292092 | 824 | cgroup.procs |
6c292092 TH |
825 | A read-write new-line separated values file which exists on |
826 | all cgroups. | |
827 | ||
828 | When read, it lists the PIDs of all processes which belong to | |
829 | the cgroup one-per-line. The PIDs are not ordered and the | |
830 | same PID may show up more than once if the process got moved | |
831 | to another cgroup and then back or the PID got recycled while | |
832 | reading. | |
833 | ||
834 | A PID can be written to migrate the process associated with | |
835 | the PID to the cgroup. The writer should match all of the | |
836 | following conditions. | |
837 | ||
6c292092 | 838 | - It must have write access to the "cgroup.procs" file. |
8cfd8147 TH |
839 | |
840 | - It must have write access to the "cgroup.procs" file of the | |
841 | common ancestor of the source and destination cgroups. | |
842 | ||
843 | When delegating a sub-hierarchy, write access to this file | |
844 | should be granted along with the containing directory. | |
845 | ||
846 | In a threaded cgroup, reading this file fails with EOPNOTSUPP | |
847 | as all the processes belong to the thread root. Writing is | |
848 | supported and moves every thread of the process to the cgroup. | |
849 | ||
850 | cgroup.threads | |
851 | A read-write new-line separated values file which exists on | |
852 | all cgroups. | |
853 | ||
854 | When read, it lists the TIDs of all threads which belong to | |
855 | the cgroup one-per-line. The TIDs are not ordered and the | |
856 | same TID may show up more than once if the thread got moved to | |
857 | another cgroup and then back or the TID got recycled while | |
858 | reading. | |
859 | ||
860 | A TID can be written to migrate the thread associated with the | |
861 | TID to the cgroup. The writer should match all of the | |
862 | following conditions. | |
863 | ||
864 | - It must have write access to the "cgroup.threads" file. | |
865 | ||
866 | - The cgroup that the thread is currently in must be in the | |
867 | same resource domain as the destination cgroup. | |
6c292092 TH |
868 | |
869 | - It must have write access to the "cgroup.procs" file of the | |
870 | common ancestor of the source and destination cgroups. | |
871 | ||
872 | When delegating a sub-hierarchy, write access to this file | |
873 | should be granted along with the containing directory. | |
874 | ||
875 | cgroup.controllers | |
6c292092 TH |
876 | A read-only space separated values file which exists on all |
877 | cgroups. | |
878 | ||
879 | It shows space separated list of all controllers available to | |
880 | the cgroup. The controllers are not ordered. | |
881 | ||
882 | cgroup.subtree_control | |
6c292092 TH |
883 | A read-write space separated values file which exists on all |
884 | cgroups. Starts out empty. | |
885 | ||
886 | When read, it shows space separated list of the controllers | |
887 | which are enabled to control resource distribution from the | |
888 | cgroup to its children. | |
889 | ||
890 | Space separated list of controllers prefixed with '+' or '-' | |
891 | can be written to enable or disable controllers. A controller | |
892 | name prefixed with '+' enables the controller and '-' | |
893 | disables. If a controller appears more than once on the list, | |
894 | the last one is effective. When multiple enable and disable | |
895 | operations are specified, either all succeed or all fail. | |
896 | ||
897 | cgroup.events | |
6c292092 TH |
898 | A read-only flat-keyed file which exists on non-root cgroups. |
899 | The following entries are defined. Unless specified | |
900 | otherwise, a value change in this file generates a file | |
901 | modified event. | |
902 | ||
903 | populated | |
6c292092 TH |
904 | 1 if the cgroup or its descendants contains any live |
905 | processes; otherwise, 0. | |
afe471ea RG |
906 | frozen |
907 | 1 if the cgroup is frozen; otherwise, 0. | |
6c292092 | 908 | |
1a926e0b RG |
909 | cgroup.max.descendants |
910 | A read-write single value files. The default is "max". | |
911 | ||
912 | Maximum allowed number of descent cgroups. | |
913 | If the actual number of descendants is equal or larger, | |
914 | an attempt to create a new cgroup in the hierarchy will fail. | |
915 | ||
916 | cgroup.max.depth | |
917 | A read-write single value files. The default is "max". | |
918 | ||
919 | Maximum allowed descent depth below the current cgroup. | |
920 | If the actual descent depth is equal or larger, | |
921 | an attempt to create a new child cgroup will fail. | |
922 | ||
ec39225c RG |
923 | cgroup.stat |
924 | A read-only flat-keyed file with the following entries: | |
925 | ||
926 | nr_descendants | |
927 | Total number of visible descendant cgroups. | |
928 | ||
929 | nr_dying_descendants | |
930 | Total number of dying descendant cgroups. A cgroup becomes | |
931 | dying after being deleted by a user. The cgroup will remain | |
932 | in dying state for some time undefined time (which can depend | |
933 | on system load) before being completely destroyed. | |
934 | ||
935 | A process can't enter a dying cgroup under any circumstances, | |
936 | a dying cgroup can't revive. | |
937 | ||
938 | A dying cgroup can consume system resources not exceeding | |
939 | limits, which were active at the moment of cgroup deletion. | |
940 | ||
afe471ea RG |
941 | cgroup.freeze |
942 | A read-write single value file which exists on non-root cgroups. | |
943 | Allowed values are "0" and "1". The default is "0". | |
944 | ||
945 | Writing "1" to the file causes freezing of the cgroup and all | |
946 | descendant cgroups. This means that all belonging processes will | |
947 | be stopped and will not run until the cgroup will be explicitly | |
948 | unfrozen. Freezing of the cgroup may take some time; when this action | |
949 | is completed, the "frozen" value in the cgroup.events control file | |
950 | will be updated to "1" and the corresponding notification will be | |
951 | issued. | |
952 | ||
953 | A cgroup can be frozen either by its own settings, or by settings | |
954 | of any ancestor cgroups. If any of ancestor cgroups is frozen, the | |
955 | cgroup will remain frozen. | |
956 | ||
957 | Processes in the frozen cgroup can be killed by a fatal signal. | |
958 | They also can enter and leave a frozen cgroup: either by an explicit | |
959 | move by a user, or if freezing of the cgroup races with fork(). | |
960 | If a process is moved to a frozen cgroup, it stops. If a process is | |
961 | moved out of a frozen cgroup, it becomes running. | |
962 | ||
963 | Frozen status of a cgroup doesn't affect any cgroup tree operations: | |
964 | it's possible to delete a frozen (and empty) cgroup, as well as | |
965 | create new sub-cgroups. | |
6c292092 | 966 | |
340272b0 CB |
967 | cgroup.kill |
968 | A write-only single value file which exists in non-root cgroups. | |
969 | The only allowed value is "1". | |
970 | ||
971 | Writing "1" to the file causes the cgroup and all descendant cgroups to | |
972 | be killed. This means that all processes located in the affected cgroup | |
973 | tree will be killed via SIGKILL. | |
974 | ||
975 | Killing a cgroup tree will deal with concurrent forks appropriately and | |
976 | is protected against migrations. | |
977 | ||
978 | In a threaded cgroup, writing this file fails with EOPNOTSUPP as | |
979 | killing cgroups is a process directed operation, i.e. it affects | |
980 | the whole thread-group. | |
981 | ||
34f26a15 CZ |
982 | cgroup.pressure |
983 | A read-write single value file that allowed values are "0" and "1". | |
984 | The default is "1". | |
985 | ||
986 | Writing "0" to the file will disable the cgroup PSI accounting. | |
987 | Writing "1" to the file will re-enable the cgroup PSI accounting. | |
988 | ||
989 | This control attribute is not hierarchical, so disable or enable PSI | |
990 | accounting in a cgroup does not affect PSI accounting in descendants | |
991 | and doesn't need pass enablement via ancestors from root. | |
992 | ||
993 | The reason this control attribute exists is that PSI accounts stalls for | |
994 | each cgroup separately and aggregates it at each level of the hierarchy. | |
995 | This may cause non-negligible overhead for some workloads when under | |
996 | deep level of the hierarchy, in which case this control attribute can | |
997 | be used to disable PSI accounting in the non-leaf cgroups. | |
998 | ||
52b1364b CZ |
999 | irq.pressure |
1000 | A read-write nested-keyed file. | |
1001 | ||
1002 | Shows pressure stall information for IRQ/SOFTIRQ. See | |
1003 | :ref:`Documentation/accounting/psi.rst <psi>` for details. | |
1004 | ||
633b11be MCC |
1005 | Controllers |
1006 | =========== | |
6c292092 | 1007 | |
e5ba9ea6 KK |
1008 | .. _cgroup-v2-cpu: |
1009 | ||
633b11be MCC |
1010 | CPU |
1011 | --- | |
6c292092 | 1012 | |
6c292092 TH |
1013 | The "cpu" controllers regulates distribution of CPU cycles. This |
1014 | controller implements weight and absolute bandwidth limit models for | |
1015 | normal scheduling policy and absolute bandwidth allocation model for | |
1016 | realtime scheduling policy. | |
1017 | ||
2480c093 PB |
1018 | In all the above models, cycles distribution is defined only on a temporal |
1019 | base and it does not account for the frequency at which tasks are executed. | |
1020 | The (optional) utilization clamping support allows to hint the schedutil | |
1021 | cpufreq governor about the minimum desired frequency which should always be | |
1022 | provided by a CPU, as well as the maximum desired frequency, which should not | |
1023 | be exceeded by a CPU. | |
1024 | ||
c2f31b79 TH |
1025 | WARNING: cgroup2 doesn't yet support control of realtime processes and |
1026 | the cpu controller can only be enabled when all RT processes are in | |
1027 | the root cgroup. Be aware that system management software may already | |
1028 | have placed RT processes into nonroot cgroups during the system boot | |
1029 | process, and these processes may need to be moved to the root cgroup | |
1030 | before the cpu controller can be enabled. | |
1031 | ||
6c292092 | 1032 | |
633b11be MCC |
1033 | CPU Interface Files |
1034 | ~~~~~~~~~~~~~~~~~~~ | |
6c292092 TH |
1035 | |
1036 | All time durations are in microseconds. | |
1037 | ||
1038 | cpu.stat | |
936f2a70 | 1039 | A read-only flat-keyed file. |
d41bf8c9 | 1040 | This file exists whether the controller is enabled or not. |
6c292092 | 1041 | |
d41bf8c9 | 1042 | It always reports the following three stats: |
6c292092 | 1043 | |
633b11be MCC |
1044 | - usage_usec |
1045 | - user_usec | |
1046 | - system_usec | |
d41bf8c9 TH |
1047 | |
1048 | and the following three when the controller is enabled: | |
1049 | ||
633b11be MCC |
1050 | - nr_periods |
1051 | - nr_throttled | |
1052 | - throttled_usec | |
d73df887 HC |
1053 | - nr_bursts |
1054 | - burst_usec | |
6c292092 TH |
1055 | |
1056 | cpu.weight | |
6c292092 TH |
1057 | A read-write single value file which exists on non-root |
1058 | cgroups. The default is "100". | |
1059 | ||
1060 | The weight in the range [1, 10000]. | |
1061 | ||
0d593634 TH |
1062 | cpu.weight.nice |
1063 | A read-write single value file which exists on non-root | |
1064 | cgroups. The default is "0". | |
1065 | ||
1066 | The nice value is in the range [-20, 19]. | |
1067 | ||
1068 | This interface file is an alternative interface for | |
1069 | "cpu.weight" and allows reading and setting weight using the | |
1070 | same values used by nice(2). Because the range is smaller and | |
1071 | granularity is coarser for the nice values, the read value is | |
1072 | the closest approximation of the current weight. | |
1073 | ||
6c292092 | 1074 | cpu.max |
6c292092 TH |
1075 | A read-write two value file which exists on non-root cgroups. |
1076 | The default is "max 100000". | |
1077 | ||
633b11be | 1078 | The maximum bandwidth limit. It's in the following format:: |
6c292092 TH |
1079 | |
1080 | $MAX $PERIOD | |
1081 | ||
dbeb56fe | 1082 | which indicates that the group may consume up to $MAX in each |
6c292092 TH |
1083 | $PERIOD duration. "max" for $MAX indicates no limit. If only |
1084 | one number is written, $MAX is updated. | |
1085 | ||
d73df887 HC |
1086 | cpu.max.burst |
1087 | A read-write single value file which exists on non-root | |
1088 | cgroups. The default is "0". | |
1089 | ||
1090 | The burst in the range [0, $MAX]. | |
1091 | ||
2ce7135a | 1092 | cpu.pressure |
74bdd45c | 1093 | A read-write nested-keyed file. |
2ce7135a JW |
1094 | |
1095 | Shows pressure stall information for CPU. See | |
373e8ffa | 1096 | :ref:`Documentation/accounting/psi.rst <psi>` for details. |
2ce7135a | 1097 | |
2480c093 PB |
1098 | cpu.uclamp.min |
1099 | A read-write single value file which exists on non-root cgroups. | |
1100 | The default is "0", i.e. no utilization boosting. | |
1101 | ||
1102 | The requested minimum utilization (protection) as a percentage | |
1103 | rational number, e.g. 12.34 for 12.34%. | |
1104 | ||
1105 | This interface allows reading and setting minimum utilization clamp | |
1106 | values similar to the sched_setattr(2). This minimum utilization | |
1107 | value is used to clamp the task specific minimum utilization clamp. | |
1108 | ||
1109 | The requested minimum utilization (protection) is always capped by | |
1110 | the current value for the maximum utilization (limit), i.e. | |
1111 | `cpu.uclamp.max`. | |
1112 | ||
1113 | cpu.uclamp.max | |
1114 | A read-write single value file which exists on non-root cgroups. | |
1115 | The default is "max". i.e. no utilization capping | |
1116 | ||
1117 | The requested maximum utilization (limit) as a percentage rational | |
1118 | number, e.g. 98.76 for 98.76%. | |
1119 | ||
1120 | This interface allows reading and setting maximum utilization clamp | |
1121 | values similar to the sched_setattr(2). This maximum utilization | |
1122 | value is used to clamp the task specific maximum utilization clamp. | |
1123 | ||
1124 | ||
6c292092 | 1125 | |
633b11be MCC |
1126 | Memory |
1127 | ------ | |
6c292092 TH |
1128 | |
1129 | The "memory" controller regulates distribution of memory. Memory is | |
1130 | stateful and implements both limit and protection models. Due to the | |
1131 | intertwining between memory usage and reclaim pressure and the | |
1132 | stateful nature of memory, the distribution model is relatively | |
1133 | complex. | |
1134 | ||
1135 | While not completely water-tight, all major memory usages by a given | |
1136 | cgroup are tracked so that the total memory consumption can be | |
1137 | accounted and controlled to a reasonable extent. Currently, the | |
1138 | following types of memory usages are tracked. | |
1139 | ||
1140 | - Userland memory - page cache and anonymous memory. | |
1141 | ||
1142 | - Kernel data structures such as dentries and inodes. | |
1143 | ||
1144 | - TCP socket buffers. | |
1145 | ||
1146 | The above list may expand in the future for better coverage. | |
1147 | ||
1148 | ||
633b11be MCC |
1149 | Memory Interface Files |
1150 | ~~~~~~~~~~~~~~~~~~~~~~ | |
6c292092 TH |
1151 | |
1152 | All memory amounts are in bytes. If a value which is not aligned to | |
1153 | PAGE_SIZE is written, the value may be rounded up to the closest | |
1154 | PAGE_SIZE multiple when read back. | |
1155 | ||
1156 | memory.current | |
6c292092 TH |
1157 | A read-only single value file which exists on non-root |
1158 | cgroups. | |
1159 | ||
1160 | The total amount of memory currently being used by the cgroup | |
1161 | and its descendants. | |
1162 | ||
bf8d5d52 RG |
1163 | memory.min |
1164 | A read-write single value file which exists on non-root | |
1165 | cgroups. The default is "0". | |
1166 | ||
1167 | Hard memory protection. If the memory usage of a cgroup | |
1168 | is within its effective min boundary, the cgroup's memory | |
1169 | won't be reclaimed under any conditions. If there is no | |
1170 | unprotected reclaimable memory available, OOM killer | |
9783aa99 CD |
1171 | is invoked. Above the effective min boundary (or |
1172 | effective low boundary if it is higher), pages are reclaimed | |
1173 | proportionally to the overage, reducing reclaim pressure for | |
1174 | smaller overages. | |
bf8d5d52 | 1175 | |
d0c3bacb | 1176 | Effective min boundary is limited by memory.min values of |
bf8d5d52 RG |
1177 | all ancestor cgroups. If there is memory.min overcommitment |
1178 | (child cgroup or cgroups are requiring more protected memory | |
1179 | than parent will allow), then each child cgroup will get | |
1180 | the part of parent's protection proportional to its | |
1181 | actual memory usage below memory.min. | |
1182 | ||
1183 | Putting more memory than generally available under this | |
1184 | protection is discouraged and may lead to constant OOMs. | |
1185 | ||
1186 | If a memory cgroup is not populated with processes, | |
1187 | its memory.min is ignored. | |
1188 | ||
6c292092 | 1189 | memory.low |
6c292092 TH |
1190 | A read-write single value file which exists on non-root |
1191 | cgroups. The default is "0". | |
1192 | ||
7854207f RG |
1193 | Best-effort memory protection. If the memory usage of a |
1194 | cgroup is within its effective low boundary, the cgroup's | |
6ee0fac1 JH |
1195 | memory won't be reclaimed unless there is no reclaimable |
1196 | memory available in unprotected cgroups. | |
822bbba0 | 1197 | Above the effective low boundary (or |
9783aa99 CD |
1198 | effective min boundary if it is higher), pages are reclaimed |
1199 | proportionally to the overage, reducing reclaim pressure for | |
1200 | smaller overages. | |
7854207f RG |
1201 | |
1202 | Effective low boundary is limited by memory.low values of | |
1203 | all ancestor cgroups. If there is memory.low overcommitment | |
bf8d5d52 | 1204 | (child cgroup or cgroups are requiring more protected memory |
7854207f | 1205 | than parent will allow), then each child cgroup will get |
bf8d5d52 | 1206 | the part of parent's protection proportional to its |
7854207f | 1207 | actual memory usage below memory.low. |
6c292092 TH |
1208 | |
1209 | Putting more memory than generally available under this | |
1210 | protection is discouraged. | |
1211 | ||
1212 | memory.high | |
6c292092 TH |
1213 | A read-write single value file which exists on non-root |
1214 | cgroups. The default is "max". | |
1215 | ||
5647e53f | 1216 | Memory usage throttle limit. If a cgroup's usage goes |
6c292092 TH |
1217 | over the high boundary, the processes of the cgroup are |
1218 | throttled and put under heavy reclaim pressure. | |
1219 | ||
1220 | Going over the high limit never invokes the OOM killer and | |
5647e53f DS |
1221 | under extreme conditions the limit may be breached. The high |
1222 | limit should be used in scenarios where an external process | |
1223 | monitors the limited cgroup to alleviate heavy reclaim | |
1224 | pressure. | |
6c292092 TH |
1225 | |
1226 | memory.max | |
6c292092 TH |
1227 | A read-write single value file which exists on non-root |
1228 | cgroups. The default is "max". | |
1229 | ||
5647e53f DS |
1230 | Memory usage hard limit. This is the main mechanism to limit |
1231 | memory usage of a cgroup. If a cgroup's memory usage reaches | |
1232 | this limit and can't be reduced, the OOM killer is invoked in | |
1233 | the cgroup. Under certain circumstances, the usage may go | |
1234 | over the limit temporarily. | |
6c292092 | 1235 | |
db33ec37 KK |
1236 | In default configuration regular 0-order allocations always |
1237 | succeed unless OOM killer chooses current task as a victim. | |
1238 | ||
1239 | Some kinds of allocations don't invoke the OOM killer. | |
1240 | Caller could retry them differently, return into userspace | |
1241 | as -ENOMEM or silently ignore in cases like disk readahead. | |
1242 | ||
94968384 SB |
1243 | memory.reclaim |
1244 | A write-only nested-keyed file which exists for all cgroups. | |
1245 | ||
1246 | This is a simple interface to trigger memory reclaim in the | |
1247 | target cgroup. | |
1248 | ||
55ab834a MH |
1249 | This file accepts a single key, the number of bytes to reclaim. |
1250 | No nested keys are currently supported. | |
94968384 SB |
1251 | |
1252 | Example:: | |
1253 | ||
1254 | echo "1G" > memory.reclaim | |
1255 | ||
55ab834a MH |
1256 | The interface can be later extended with nested keys to |
1257 | configure the reclaim behavior. For example, specify the | |
1258 | type of memory to reclaim from (anon, file, ..). | |
1259 | ||
94968384 SB |
1260 | Please note that the kernel can over or under reclaim from |
1261 | the target cgroup. If less bytes are reclaimed than the | |
1262 | specified amount, -EAGAIN is returned. | |
1263 | ||
73b73bac YA |
1264 | Please note that the proactive reclaim (triggered by this |
1265 | interface) is not meant to indicate memory pressure on the | |
1266 | memory cgroup. Therefore socket memory balancing triggered by | |
1267 | the memory reclaim normally is not exercised in this case. | |
1268 | This means that the networking layer will not adapt based on | |
1269 | reclaim induced by memory.reclaim. | |
1270 | ||
8e20d4b3 GR |
1271 | memory.peak |
1272 | A read-only single value file which exists on non-root | |
1273 | cgroups. | |
1274 | ||
1275 | The max memory usage recorded for the cgroup and its | |
1276 | descendants since the creation of the cgroup. | |
1277 | ||
3d8b38eb RG |
1278 | memory.oom.group |
1279 | A read-write single value file which exists on non-root | |
1280 | cgroups. The default value is "0". | |
1281 | ||
1282 | Determines whether the cgroup should be treated as | |
1283 | an indivisible workload by the OOM killer. If set, | |
1284 | all tasks belonging to the cgroup or to its descendants | |
1285 | (if the memory cgroup is not a leaf cgroup) are killed | |
1286 | together or not at all. This can be used to avoid | |
1287 | partial kills to guarantee workload integrity. | |
1288 | ||
1289 | Tasks with the OOM protection (oom_score_adj set to -1000) | |
1290 | are treated as an exception and are never killed. | |
1291 | ||
1292 | If the OOM killer is invoked in a cgroup, it's not going | |
1293 | to kill any tasks outside of this cgroup, regardless | |
1294 | memory.oom.group values of ancestor cgroups. | |
1295 | ||
6c292092 | 1296 | memory.events |
6c292092 TH |
1297 | A read-only flat-keyed file which exists on non-root cgroups. |
1298 | The following entries are defined. Unless specified | |
1299 | otherwise, a value change in this file generates a file | |
1300 | modified event. | |
1301 | ||
1e577f97 SB |
1302 | Note that all fields in this file are hierarchical and the |
1303 | file modified event can be generated due to an event down the | |
22b12557 | 1304 | hierarchy. For the local events at the cgroup level see |
1e577f97 SB |
1305 | memory.events.local. |
1306 | ||
6c292092 | 1307 | low |
6c292092 TH |
1308 | The number of times the cgroup is reclaimed due to |
1309 | high memory pressure even though its usage is under | |
1310 | the low boundary. This usually indicates that the low | |
1311 | boundary is over-committed. | |
1312 | ||
1313 | high | |
6c292092 TH |
1314 | The number of times processes of the cgroup are |
1315 | throttled and routed to perform direct memory reclaim | |
1316 | because the high memory boundary was exceeded. For a | |
1317 | cgroup whose memory usage is capped by the high limit | |
1318 | rather than global memory pressure, this event's | |
1319 | occurrences are expected. | |
1320 | ||
1321 | max | |
6c292092 TH |
1322 | The number of times the cgroup's memory usage was |
1323 | about to go over the max boundary. If direct reclaim | |
8e675f7a | 1324 | fails to bring it down, the cgroup goes to OOM state. |
6c292092 TH |
1325 | |
1326 | oom | |
8e675f7a KK |
1327 | The number of time the cgroup's memory usage was |
1328 | reached the limit and allocation was about to fail. | |
1329 | ||
7a1adfdd RG |
1330 | This event is not raised if the OOM killer is not |
1331 | considered as an option, e.g. for failed high-order | |
db33ec37 | 1332 | allocations or if caller asked to not retry attempts. |
7a1adfdd | 1333 | |
8e675f7a | 1334 | oom_kill |
8e675f7a KK |
1335 | The number of processes belonging to this cgroup |
1336 | killed by any kind of OOM killer. | |
6c292092 | 1337 | |
b6bf9abb DS |
1338 | oom_group_kill |
1339 | The number of times a group OOM has occurred. | |
1340 | ||
1e577f97 SB |
1341 | memory.events.local |
1342 | Similar to memory.events but the fields in the file are local | |
1343 | to the cgroup i.e. not hierarchical. The file modified event | |
1344 | generated on this file reflects only the local events. | |
1345 | ||
587d9f72 | 1346 | memory.stat |
587d9f72 JW |
1347 | A read-only flat-keyed file which exists on non-root cgroups. |
1348 | ||
1349 | This breaks down the cgroup's memory footprint into different | |
1350 | types of memory, type-specific details, and other information | |
1351 | on the state and past events of the memory management system. | |
1352 | ||
1353 | All memory amounts are in bytes. | |
1354 | ||
1355 | The entries are ordered to be human readable, and new entries | |
1356 | can show up in the middle. Don't rely on items remaining in a | |
1357 | fixed position; use the keys to look up specific values! | |
1358 | ||
a21e7bb3 KK |
1359 | If the entry has no per-node counter (or not show in the |
1360 | memory.numa_stat). We use 'npn' (non-per-node) as the tag | |
1361 | to indicate that it will not show in the memory.numa_stat. | |
5f9a4f4a | 1362 | |
587d9f72 | 1363 | anon |
587d9f72 JW |
1364 | Amount of memory used in anonymous mappings such as |
1365 | brk(), sbrk(), and mmap(MAP_ANONYMOUS) | |
1366 | ||
1367 | file | |
587d9f72 JW |
1368 | Amount of memory used to cache filesystem data, |
1369 | including tmpfs and shared memory. | |
1370 | ||
a8c49af3 YA |
1371 | kernel (npn) |
1372 | Amount of total kernel memory, including | |
1373 | (kernel_stack, pagetables, percpu, vmalloc, slab) in | |
1374 | addition to other kernel memory use cases. | |
1375 | ||
12580e4b | 1376 | kernel_stack |
12580e4b VD |
1377 | Amount of memory allocated to kernel stacks. |
1378 | ||
f0c0c115 SB |
1379 | pagetables |
1380 | Amount of memory allocated for page tables. | |
1381 | ||
ebc97a52 YA |
1382 | sec_pagetables |
1383 | Amount of memory allocated for secondary page tables, | |
1384 | this currently includes KVM mmu allocations on x86 | |
1385 | and arm64. | |
1386 | ||
a21e7bb3 | 1387 | percpu (npn) |
772616b0 RG |
1388 | Amount of memory used for storing per-cpu kernel |
1389 | data structures. | |
1390 | ||
a21e7bb3 | 1391 | sock (npn) |
4758e198 JW |
1392 | Amount of memory used in network transmission buffers |
1393 | ||
4e5aa1f4 SB |
1394 | vmalloc (npn) |
1395 | Amount of memory used for vmap backed memory. | |
1396 | ||
9a4caf1e | 1397 | shmem |
9a4caf1e JW |
1398 | Amount of cached filesystem data that is swap-backed, |
1399 | such as tmpfs, shm segments, shared anonymous mmap()s | |
1400 | ||
f4840ccf JW |
1401 | zswap |
1402 | Amount of memory consumed by the zswap compression backend. | |
1403 | ||
1404 | zswapped | |
1405 | Amount of application memory swapped out to zswap. | |
1406 | ||
587d9f72 | 1407 | file_mapped |
587d9f72 JW |
1408 | Amount of cached filesystem data mapped with mmap() |
1409 | ||
1410 | file_dirty | |
587d9f72 JW |
1411 | Amount of cached filesystem data that was modified but |
1412 | not yet written back to disk | |
1413 | ||
1414 | file_writeback | |
587d9f72 JW |
1415 | Amount of cached filesystem data that was modified and |
1416 | is currently being written back to disk | |
1417 | ||
b6038942 SB |
1418 | swapcached |
1419 | Amount of swap cached in memory. The swapcache is accounted | |
1420 | against both memory and swap usage. | |
1421 | ||
1ff9e6e1 CD |
1422 | anon_thp |
1423 | Amount of memory used in anonymous mappings backed by | |
1424 | transparent hugepages | |
b8eddff8 JW |
1425 | |
1426 | file_thp | |
1427 | Amount of cached filesystem data backed by transparent | |
1428 | hugepages | |
1429 | ||
1430 | shmem_thp | |
1431 | Amount of shm, tmpfs, shared anonymous mmap()s backed by | |
1432 | transparent hugepages | |
1ff9e6e1 | 1433 | |
633b11be | 1434 | inactive_anon, active_anon, inactive_file, active_file, unevictable |
587d9f72 JW |
1435 | Amount of memory, swap-backed and filesystem-backed, |
1436 | on the internal memory management lists used by the | |
1603c8d1 CD |
1437 | page reclaim algorithm. |
1438 | ||
1439 | As these represent internal list state (eg. shmem pages are on anon | |
1440 | memory management lists), inactive_foo + active_foo may not be equal to | |
1441 | the value for the foo counter, since the foo counter is type-based, not | |
1442 | list-based. | |
587d9f72 | 1443 | |
27ee57c9 | 1444 | slab_reclaimable |
27ee57c9 VD |
1445 | Part of "slab" that might be reclaimed, such as |
1446 | dentries and inodes. | |
1447 | ||
1448 | slab_unreclaimable | |
27ee57c9 VD |
1449 | Part of "slab" that cannot be reclaimed on memory |
1450 | pressure. | |
1451 | ||
a21e7bb3 | 1452 | slab (npn) |
5f9a4f4a MS |
1453 | Amount of memory used for storing in-kernel data |
1454 | structures. | |
587d9f72 | 1455 | |
8d3fe09d MS |
1456 | workingset_refault_anon |
1457 | Number of refaults of previously evicted anonymous pages. | |
b340959e | 1458 | |
8d3fe09d MS |
1459 | workingset_refault_file |
1460 | Number of refaults of previously evicted file pages. | |
b340959e | 1461 | |
8d3fe09d MS |
1462 | workingset_activate_anon |
1463 | Number of refaulted anonymous pages that were immediately | |
1464 | activated. | |
1465 | ||
1466 | workingset_activate_file | |
1467 | Number of refaulted file pages that were immediately activated. | |
1468 | ||
1469 | workingset_restore_anon | |
1470 | Number of restored anonymous pages which have been detected as | |
1471 | an active workingset before they got reclaimed. | |
1472 | ||
1473 | workingset_restore_file | |
1474 | Number of restored file pages which have been detected as an | |
1475 | active workingset before they got reclaimed. | |
a6f5576b | 1476 | |
b340959e | 1477 | workingset_nodereclaim |
b340959e RG |
1478 | Number of times a shadow node has been reclaimed |
1479 | ||
673520f8 QZ |
1480 | pgscan (npn) |
1481 | Amount of scanned pages (in an inactive LRU list) | |
1482 | ||
1483 | pgsteal (npn) | |
1484 | Amount of reclaimed pages | |
1485 | ||
1486 | pgscan_kswapd (npn) | |
1487 | Amount of scanned pages by kswapd (in an inactive LRU list) | |
1488 | ||
1489 | pgscan_direct (npn) | |
1490 | Amount of scanned pages directly (in an inactive LRU list) | |
1491 | ||
57e9cc50 JW |
1492 | pgscan_khugepaged (npn) |
1493 | Amount of scanned pages by khugepaged (in an inactive LRU list) | |
1494 | ||
673520f8 QZ |
1495 | pgsteal_kswapd (npn) |
1496 | Amount of reclaimed pages by kswapd | |
1497 | ||
1498 | pgsteal_direct (npn) | |
1499 | Amount of reclaimed pages directly | |
1500 | ||
57e9cc50 JW |
1501 | pgsteal_khugepaged (npn) |
1502 | Amount of reclaimed pages by khugepaged | |
1503 | ||
a21e7bb3 | 1504 | pgfault (npn) |
5f9a4f4a MS |
1505 | Total number of page faults incurred |
1506 | ||
a21e7bb3 | 1507 | pgmajfault (npn) |
5f9a4f4a MS |
1508 | Number of major page faults incurred |
1509 | ||
a21e7bb3 | 1510 | pgrefill (npn) |
2262185c RG |
1511 | Amount of scanned pages (in an active LRU list) |
1512 | ||
a21e7bb3 | 1513 | pgactivate (npn) |
2262185c RG |
1514 | Amount of pages moved to the active LRU list |
1515 | ||
a21e7bb3 | 1516 | pgdeactivate (npn) |
03189e8e | 1517 | Amount of pages moved to the inactive LRU list |
2262185c | 1518 | |
a21e7bb3 | 1519 | pglazyfree (npn) |
2262185c RG |
1520 | Amount of pages postponed to be freed under memory pressure |
1521 | ||
a21e7bb3 | 1522 | pglazyfreed (npn) |
2262185c RG |
1523 | Amount of reclaimed lazyfree pages |
1524 | ||
a21e7bb3 | 1525 | thp_fault_alloc (npn) |
1ff9e6e1 | 1526 | Number of transparent hugepages which were allocated to satisfy |
2a8bef32 YS |
1527 | a page fault. This counter is not present when CONFIG_TRANSPARENT_HUGEPAGE |
1528 | is not set. | |
1ff9e6e1 | 1529 | |
a21e7bb3 | 1530 | thp_collapse_alloc (npn) |
1ff9e6e1 CD |
1531 | Number of transparent hugepages which were allocated to allow |
1532 | collapsing an existing range of pages. This counter is not | |
1533 | present when CONFIG_TRANSPARENT_HUGEPAGE is not set. | |
1534 | ||
5f9a4f4a MS |
1535 | memory.numa_stat |
1536 | A read-only nested-keyed file which exists on non-root cgroups. | |
1537 | ||
1538 | This breaks down the cgroup's memory footprint into different | |
1539 | types of memory, type-specific details, and other information | |
1540 | per node on the state of the memory management system. | |
1541 | ||
1542 | This is useful for providing visibility into the NUMA locality | |
1543 | information within an memcg since the pages are allowed to be | |
1544 | allocated from any physical node. One of the use case is evaluating | |
1545 | application performance by combining this information with the | |
1546 | application's CPU allocation. | |
1547 | ||
1548 | All memory amounts are in bytes. | |
1549 | ||
1550 | The output format of memory.numa_stat is:: | |
1551 | ||
1552 | type N0=<bytes in node 0> N1=<bytes in node 1> ... | |
1553 | ||
1554 | The entries are ordered to be human readable, and new entries | |
1555 | can show up in the middle. Don't rely on items remaining in a | |
1556 | fixed position; use the keys to look up specific values! | |
1557 | ||
1558 | The entries can refer to the memory.stat. | |
1559 | ||
3e24b19d | 1560 | memory.swap.current |
3e24b19d VD |
1561 | A read-only single value file which exists on non-root |
1562 | cgroups. | |
1563 | ||
1564 | The total amount of swap currently being used by the cgroup | |
1565 | and its descendants. | |
1566 | ||
4b82ab4f JK |
1567 | memory.swap.high |
1568 | A read-write single value file which exists on non-root | |
1569 | cgroups. The default is "max". | |
1570 | ||
1571 | Swap usage throttle limit. If a cgroup's swap usage exceeds | |
1572 | this limit, all its further allocations will be throttled to | |
1573 | allow userspace to implement custom out-of-memory procedures. | |
1574 | ||
1575 | This limit marks a point of no return for the cgroup. It is NOT | |
1576 | designed to manage the amount of swapping a workload does | |
1577 | during regular operation. Compare to memory.swap.max, which | |
1578 | prohibits swapping past a set amount, but lets the cgroup | |
1579 | continue unimpeded as long as other memory can be reclaimed. | |
1580 | ||
1581 | Healthy workloads are not expected to reach this limit. | |
1582 | ||
3e24b19d | 1583 | memory.swap.max |
3e24b19d VD |
1584 | A read-write single value file which exists on non-root |
1585 | cgroups. The default is "max". | |
1586 | ||
1587 | Swap usage hard limit. If a cgroup's swap usage reaches this | |
2877cbe6 | 1588 | limit, anonymous memory of the cgroup will not be swapped out. |
3e24b19d | 1589 | |
f3a53a3a TH |
1590 | memory.swap.events |
1591 | A read-only flat-keyed file which exists on non-root cgroups. | |
1592 | The following entries are defined. Unless specified | |
1593 | otherwise, a value change in this file generates a file | |
1594 | modified event. | |
1595 | ||
4b82ab4f JK |
1596 | high |
1597 | The number of times the cgroup's swap usage was over | |
1598 | the high threshold. | |
1599 | ||
f3a53a3a TH |
1600 | max |
1601 | The number of times the cgroup's swap usage was about | |
1602 | to go over the max boundary and swap allocation | |
1603 | failed. | |
1604 | ||
1605 | fail | |
1606 | The number of times swap allocation failed either | |
1607 | because of running out of swap system-wide or max | |
1608 | limit. | |
1609 | ||
be09102b TH |
1610 | When reduced under the current usage, the existing swap |
1611 | entries are reclaimed gradually and the swap usage may stay | |
1612 | higher than the limit for an extended period of time. This | |
1613 | reduces the impact on the workload and memory management. | |
1614 | ||
f4840ccf JW |
1615 | memory.zswap.current |
1616 | A read-only single value file which exists on non-root | |
1617 | cgroups. | |
1618 | ||
1619 | The total amount of memory consumed by the zswap compression | |
1620 | backend. | |
1621 | ||
1622 | memory.zswap.max | |
1623 | A read-write single value file which exists on non-root | |
1624 | cgroups. The default is "max". | |
1625 | ||
1626 | Zswap usage hard limit. If a cgroup's zswap pool reaches this | |
1627 | limit, it will refuse to take any more stores before existing | |
1628 | entries fault back in or are written out to disk. | |
1629 | ||
2ce7135a | 1630 | memory.pressure |
74bdd45c | 1631 | A read-only nested-keyed file. |
2ce7135a JW |
1632 | |
1633 | Shows pressure stall information for memory. See | |
373e8ffa | 1634 | :ref:`Documentation/accounting/psi.rst <psi>` for details. |
2ce7135a | 1635 | |
6c292092 | 1636 | |
633b11be MCC |
1637 | Usage Guidelines |
1638 | ~~~~~~~~~~~~~~~~ | |
6c292092 TH |
1639 | |
1640 | "memory.high" is the main mechanism to control memory usage. | |
1641 | Over-committing on high limit (sum of high limits > available memory) | |
1642 | and letting global memory pressure to distribute memory according to | |
1643 | usage is a viable strategy. | |
1644 | ||
1645 | Because breach of the high limit doesn't trigger the OOM killer but | |
1646 | throttles the offending cgroup, a management agent has ample | |
1647 | opportunities to monitor and take appropriate actions such as granting | |
1648 | more memory or terminating the workload. | |
1649 | ||
1650 | Determining whether a cgroup has enough memory is not trivial as | |
1651 | memory usage doesn't indicate whether the workload can benefit from | |
1652 | more memory. For example, a workload which writes data received from | |
1653 | network to a file can use all available memory but can also operate as | |
1654 | performant with a small amount of memory. A measure of memory | |
1655 | pressure - how much the workload is being impacted due to lack of | |
1656 | memory - is necessary to determine whether a workload needs more | |
1657 | memory; unfortunately, memory pressure monitoring mechanism isn't | |
1658 | implemented yet. | |
1659 | ||
1660 | ||
633b11be MCC |
1661 | Memory Ownership |
1662 | ~~~~~~~~~~~~~~~~ | |
6c292092 TH |
1663 | |
1664 | A memory area is charged to the cgroup which instantiated it and stays | |
1665 | charged to the cgroup until the area is released. Migrating a process | |
1666 | to a different cgroup doesn't move the memory usages that it | |
1667 | instantiated while in the previous cgroup to the new cgroup. | |
1668 | ||
1669 | A memory area may be used by processes belonging to different cgroups. | |
1670 | To which cgroup the area will be charged is in-deterministic; however, | |
1671 | over time, the memory area is likely to end up in a cgroup which has | |
1672 | enough memory allowance to avoid high reclaim pressure. | |
1673 | ||
1674 | If a cgroup sweeps a considerable amount of memory which is expected | |
1675 | to be accessed repeatedly by other cgroups, it may make sense to use | |
1676 | POSIX_FADV_DONTNEED to relinquish the ownership of memory areas | |
1677 | belonging to the affected files to ensure correct memory ownership. | |
1678 | ||
1679 | ||
633b11be MCC |
1680 | IO |
1681 | -- | |
6c292092 TH |
1682 | |
1683 | The "io" controller regulates the distribution of IO resources. This | |
1684 | controller implements both weight based and absolute bandwidth or IOPS | |
1685 | limit distribution; however, weight based distribution is available | |
1686 | only if cfq-iosched is in use and neither scheme is available for | |
1687 | blk-mq devices. | |
1688 | ||
1689 | ||
633b11be MCC |
1690 | IO Interface Files |
1691 | ~~~~~~~~~~~~~~~~~~ | |
6c292092 TH |
1692 | |
1693 | io.stat | |
ef45fe47 | 1694 | A read-only nested-keyed file. |
6c292092 TH |
1695 | |
1696 | Lines are keyed by $MAJ:$MIN device numbers and not ordered. | |
1697 | The following nested keys are defined. | |
1698 | ||
636620b6 | 1699 | ====== ===================== |
6c292092 TH |
1700 | rbytes Bytes read |
1701 | wbytes Bytes written | |
1702 | rios Number of read IOs | |
1703 | wios Number of write IOs | |
636620b6 TH |
1704 | dbytes Bytes discarded |
1705 | dios Number of discard IOs | |
1706 | ====== ===================== | |
6c292092 | 1707 | |
69654d37 | 1708 | An example read output follows:: |
6c292092 | 1709 | |
636620b6 TH |
1710 | 8:16 rbytes=1459200 wbytes=314773504 rios=192 wios=353 dbytes=0 dios=0 |
1711 | 8:0 rbytes=90430464 wbytes=299008000 rios=8950 wios=1252 dbytes=50331648 dios=3021 | |
6c292092 | 1712 | |
7caa4715 | 1713 | io.cost.qos |
c4c6b86a | 1714 | A read-write nested-keyed file which exists only on the root |
7caa4715 TH |
1715 | cgroup. |
1716 | ||
1717 | This file configures the Quality of Service of the IO cost | |
1718 | model based controller (CONFIG_BLK_CGROUP_IOCOST) which | |
1719 | currently implements "io.weight" proportional control. Lines | |
1720 | are keyed by $MAJ:$MIN device numbers and not ordered. The | |
1721 | line for a given device is populated on the first write for | |
1722 | the device on "io.cost.qos" or "io.cost.model". The following | |
1723 | nested keys are defined. | |
1724 | ||
1725 | ====== ===================================== | |
1726 | enable Weight-based control enable | |
1727 | ctrl "auto" or "user" | |
1728 | rpct Read latency percentile [0, 100] | |
1729 | rlat Read latency threshold | |
1730 | wpct Write latency percentile [0, 100] | |
1731 | wlat Write latency threshold | |
1732 | min Minimum scaling percentage [1, 10000] | |
1733 | max Maximum scaling percentage [1, 10000] | |
1734 | ====== ===================================== | |
1735 | ||
1736 | The controller is disabled by default and can be enabled by | |
1737 | setting "enable" to 1. "rpct" and "wpct" parameters default | |
1738 | to zero and the controller uses internal device saturation | |
1739 | state to adjust the overall IO rate between "min" and "max". | |
1740 | ||
1741 | When a better control quality is needed, latency QoS | |
1742 | parameters can be configured. For example:: | |
1743 | ||
1744 | 8:16 enable=1 ctrl=auto rpct=95.00 rlat=75000 wpct=95.00 wlat=150000 min=50.00 max=150.0 | |
1745 | ||
1746 | shows that on sdb, the controller is enabled, will consider | |
1747 | the device saturated if the 95th percentile of read completion | |
1748 | latencies is above 75ms or write 150ms, and adjust the overall | |
1749 | IO issue rate between 50% and 150% accordingly. | |
1750 | ||
1751 | The lower the saturation point, the better the latency QoS at | |
1752 | the cost of aggregate bandwidth. The narrower the allowed | |
1753 | adjustment range between "min" and "max", the more conformant | |
1754 | to the cost model the IO behavior. Note that the IO issue | |
1755 | base rate may be far off from 100% and setting "min" and "max" | |
1756 | blindly can lead to a significant loss of device capacity or | |
1757 | control quality. "min" and "max" are useful for regulating | |
1758 | devices which show wide temporary behavior changes - e.g. a | |
1759 | ssd which accepts writes at the line speed for a while and | |
1760 | then completely stalls for multiple seconds. | |
1761 | ||
1762 | When "ctrl" is "auto", the parameters are controlled by the | |
1763 | kernel and may change automatically. Setting "ctrl" to "user" | |
1764 | or setting any of the percentile and latency parameters puts | |
1765 | it into "user" mode and disables the automatic changes. The | |
1766 | automatic mode can be restored by setting "ctrl" to "auto". | |
1767 | ||
1768 | io.cost.model | |
c4c6b86a | 1769 | A read-write nested-keyed file which exists only on the root |
7caa4715 TH |
1770 | cgroup. |
1771 | ||
1772 | This file configures the cost model of the IO cost model based | |
1773 | controller (CONFIG_BLK_CGROUP_IOCOST) which currently | |
1774 | implements "io.weight" proportional control. Lines are keyed | |
1775 | by $MAJ:$MIN device numbers and not ordered. The line for a | |
1776 | given device is populated on the first write for the device on | |
1777 | "io.cost.qos" or "io.cost.model". The following nested keys | |
1778 | are defined. | |
1779 | ||
1780 | ===== ================================ | |
1781 | ctrl "auto" or "user" | |
1782 | model The cost model in use - "linear" | |
1783 | ===== ================================ | |
1784 | ||
1785 | When "ctrl" is "auto", the kernel may change all parameters | |
1786 | dynamically. When "ctrl" is set to "user" or any other | |
1787 | parameters are written to, "ctrl" become "user" and the | |
1788 | automatic changes are disabled. | |
1789 | ||
1790 | When "model" is "linear", the following model parameters are | |
1791 | defined. | |
1792 | ||
1793 | ============= ======================================== | |
1794 | [r|w]bps The maximum sequential IO throughput | |
1795 | [r|w]seqiops The maximum 4k sequential IOs per second | |
1796 | [r|w]randiops The maximum 4k random IOs per second | |
1797 | ============= ======================================== | |
1798 | ||
1799 | From the above, the builtin linear model determines the base | |
1800 | costs of a sequential and random IO and the cost coefficient | |
1801 | for the IO size. While simple, this model can cover most | |
1802 | common device classes acceptably. | |
1803 | ||
1804 | The IO cost model isn't expected to be accurate in absolute | |
1805 | sense and is scaled to the device behavior dynamically. | |
1806 | ||
8504dea7 TH |
1807 | If needed, tools/cgroup/iocost_coef_gen.py can be used to |
1808 | generate device-specific coefficients. | |
1809 | ||
6c292092 | 1810 | io.weight |
6c292092 TH |
1811 | A read-write flat-keyed file which exists on non-root cgroups. |
1812 | The default is "default 100". | |
1813 | ||
1814 | The first line is the default weight applied to devices | |
1815 | without specific override. The rest are overrides keyed by | |
1816 | $MAJ:$MIN device numbers and not ordered. The weights are in | |
1817 | the range [1, 10000] and specifies the relative amount IO time | |
1818 | the cgroup can use in relation to its siblings. | |
1819 | ||
1820 | The default weight can be updated by writing either "default | |
1821 | $WEIGHT" or simply "$WEIGHT". Overrides can be set by writing | |
1822 | "$MAJ:$MIN $WEIGHT" and unset by writing "$MAJ:$MIN default". | |
1823 | ||
633b11be | 1824 | An example read output follows:: |
6c292092 TH |
1825 | |
1826 | default 100 | |
1827 | 8:16 200 | |
1828 | 8:0 50 | |
1829 | ||
1830 | io.max | |
6c292092 TH |
1831 | A read-write nested-keyed file which exists on non-root |
1832 | cgroups. | |
1833 | ||
1834 | BPS and IOPS based IO limit. Lines are keyed by $MAJ:$MIN | |
1835 | device numbers and not ordered. The following nested keys are | |
1836 | defined. | |
1837 | ||
633b11be | 1838 | ===== ================================== |
6c292092 TH |
1839 | rbps Max read bytes per second |
1840 | wbps Max write bytes per second | |
1841 | riops Max read IO operations per second | |
1842 | wiops Max write IO operations per second | |
633b11be | 1843 | ===== ================================== |
6c292092 TH |
1844 | |
1845 | When writing, any number of nested key-value pairs can be | |
1846 | specified in any order. "max" can be specified as the value | |
1847 | to remove a specific limit. If the same key is specified | |
1848 | multiple times, the outcome is undefined. | |
1849 | ||
1850 | BPS and IOPS are measured in each IO direction and IOs are | |
1851 | delayed if limit is reached. Temporary bursts are allowed. | |
1852 | ||
633b11be | 1853 | Setting read limit at 2M BPS and write at 120 IOPS for 8:16:: |
6c292092 TH |
1854 | |
1855 | echo "8:16 rbps=2097152 wiops=120" > io.max | |
1856 | ||
633b11be | 1857 | Reading returns the following:: |
6c292092 TH |
1858 | |
1859 | 8:16 rbps=2097152 wbps=max riops=max wiops=120 | |
1860 | ||
633b11be | 1861 | Write IOPS limit can be removed by writing the following:: |
6c292092 TH |
1862 | |
1863 | echo "8:16 wiops=max" > io.max | |
1864 | ||
633b11be | 1865 | Reading now returns the following:: |
6c292092 TH |
1866 | |
1867 | 8:16 rbps=2097152 wbps=max riops=max wiops=max | |
1868 | ||
2ce7135a | 1869 | io.pressure |
74bdd45c | 1870 | A read-only nested-keyed file. |
2ce7135a JW |
1871 | |
1872 | Shows pressure stall information for IO. See | |
373e8ffa | 1873 | :ref:`Documentation/accounting/psi.rst <psi>` for details. |
2ce7135a | 1874 | |
6c292092 | 1875 | |
633b11be MCC |
1876 | Writeback |
1877 | ~~~~~~~~~ | |
6c292092 TH |
1878 | |
1879 | Page cache is dirtied through buffered writes and shared mmaps and | |
1880 | written asynchronously to the backing filesystem by the writeback | |
1881 | mechanism. Writeback sits between the memory and IO domains and | |
1882 | regulates the proportion of dirty memory by balancing dirtying and | |
1883 | write IOs. | |
1884 | ||
1885 | The io controller, in conjunction with the memory controller, | |
1886 | implements control of page cache writeback IOs. The memory controller | |
1887 | defines the memory domain that dirty memory ratio is calculated and | |
1888 | maintained for and the io controller defines the io domain which | |
1889 | writes out dirty pages for the memory domain. Both system-wide and | |
1890 | per-cgroup dirty memory states are examined and the more restrictive | |
1891 | of the two is enforced. | |
1892 | ||
1893 | cgroup writeback requires explicit support from the underlying | |
1b932b7d ES |
1894 | filesystem. Currently, cgroup writeback is implemented on ext2, ext4, |
1895 | btrfs, f2fs, and xfs. On other filesystems, all writeback IOs are | |
1896 | attributed to the root cgroup. | |
6c292092 TH |
1897 | |
1898 | There are inherent differences in memory and writeback management | |
1899 | which affects how cgroup ownership is tracked. Memory is tracked per | |
1900 | page while writeback per inode. For the purpose of writeback, an | |
1901 | inode is assigned to a cgroup and all IO requests to write dirty pages | |
1902 | from the inode are attributed to that cgroup. | |
1903 | ||
1904 | As cgroup ownership for memory is tracked per page, there can be pages | |
1905 | which are associated with different cgroups than the one the inode is | |
1906 | associated with. These are called foreign pages. The writeback | |
1907 | constantly keeps track of foreign pages and, if a particular foreign | |
1908 | cgroup becomes the majority over a certain period of time, switches | |
1909 | the ownership of the inode to that cgroup. | |
1910 | ||
1911 | While this model is enough for most use cases where a given inode is | |
1912 | mostly dirtied by a single cgroup even when the main writing cgroup | |
1913 | changes over time, use cases where multiple cgroups write to a single | |
1914 | inode simultaneously are not supported well. In such circumstances, a | |
1915 | significant portion of IOs are likely to be attributed incorrectly. | |
1916 | As memory controller assigns page ownership on the first use and | |
1917 | doesn't update it until the page is released, even if writeback | |
1918 | strictly follows page ownership, multiple cgroups dirtying overlapping | |
1919 | areas wouldn't work as expected. It's recommended to avoid such usage | |
1920 | patterns. | |
1921 | ||
1922 | The sysctl knobs which affect writeback behavior are applied to cgroup | |
1923 | writeback as follows. | |
1924 | ||
633b11be | 1925 | vm.dirty_background_ratio, vm.dirty_ratio |
6c292092 TH |
1926 | These ratios apply the same to cgroup writeback with the |
1927 | amount of available memory capped by limits imposed by the | |
1928 | memory controller and system-wide clean memory. | |
1929 | ||
633b11be | 1930 | vm.dirty_background_bytes, vm.dirty_bytes |
6c292092 TH |
1931 | For cgroup writeback, this is calculated into ratio against |
1932 | total available memory and applied the same way as | |
1933 | vm.dirty[_background]_ratio. | |
1934 | ||
1935 | ||
b351f0c7 JB |
1936 | IO Latency |
1937 | ~~~~~~~~~~ | |
1938 | ||
1939 | This is a cgroup v2 controller for IO workload protection. You provide a group | |
1940 | with a latency target, and if the average latency exceeds that target the | |
1941 | controller will throttle any peers that have a lower latency target than the | |
1942 | protected workload. | |
1943 | ||
1944 | The limits are only applied at the peer level in the hierarchy. This means that | |
1945 | in the diagram below, only groups A, B, and C will influence each other, and | |
34b43446 | 1946 | groups D and F will influence each other. Group G will influence nobody:: |
b351f0c7 JB |
1947 | |
1948 | [root] | |
1949 | / | \ | |
1950 | A B C | |
1951 | / \ | | |
1952 | D F G | |
1953 | ||
1954 | ||
1955 | So the ideal way to configure this is to set io.latency in groups A, B, and C. | |
1956 | Generally you do not want to set a value lower than the latency your device | |
1957 | supports. Experiment to find the value that works best for your workload. | |
1958 | Start at higher than the expected latency for your device and watch the | |
c480bcf9 DZF |
1959 | avg_lat value in io.stat for your workload group to get an idea of the |
1960 | latency you see during normal operation. Use the avg_lat value as a basis for | |
1961 | your real setting, setting at 10-15% higher than the value in io.stat. | |
b351f0c7 JB |
1962 | |
1963 | How IO Latency Throttling Works | |
1964 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
1965 | ||
1966 | io.latency is work conserving; so as long as everybody is meeting their latency | |
1967 | target the controller doesn't do anything. Once a group starts missing its | |
1968 | target it begins throttling any peer group that has a higher target than itself. | |
1969 | This throttling takes 2 forms: | |
1970 | ||
1971 | - Queue depth throttling. This is the number of outstanding IO's a group is | |
1972 | allowed to have. We will clamp down relatively quickly, starting at no limit | |
1973 | and going all the way down to 1 IO at a time. | |
1974 | ||
1975 | - Artificial delay induction. There are certain types of IO that cannot be | |
1976 | throttled without possibly adversely affecting higher priority groups. This | |
1977 | includes swapping and metadata IO. These types of IO are allowed to occur | |
1978 | normally, however they are "charged" to the originating group. If the | |
1979 | originating group is being throttled you will see the use_delay and delay | |
1980 | fields in io.stat increase. The delay value is how many microseconds that are | |
1981 | being added to any process that runs in this group. Because this number can | |
1982 | grow quite large if there is a lot of swapping or metadata IO occurring we | |
1983 | limit the individual delay events to 1 second at a time. | |
1984 | ||
1985 | Once the victimized group starts meeting its latency target again it will start | |
1986 | unthrottling any peer groups that were throttled previously. If the victimized | |
1987 | group simply stops doing IO the global counter will unthrottle appropriately. | |
1988 | ||
1989 | IO Latency Interface Files | |
1990 | ~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
1991 | ||
1992 | io.latency | |
1993 | This takes a similar format as the other controllers. | |
1994 | ||
a477b94d | 1995 | "MAJOR:MINOR target=<target time in microseconds>" |
b351f0c7 JB |
1996 | |
1997 | io.stat | |
1998 | If the controller is enabled you will see extra stats in io.stat in | |
1999 | addition to the normal ones. | |
2000 | ||
2001 | depth | |
2002 | This is the current queue depth for the group. | |
2003 | ||
2004 | avg_lat | |
c480bcf9 DZF |
2005 | This is an exponential moving average with a decay rate of 1/exp |
2006 | bound by the sampling interval. The decay rate interval can be | |
2007 | calculated by multiplying the win value in io.stat by the | |
2008 | corresponding number of samples based on the win value. | |
2009 | ||
2010 | win | |
2011 | The sampling window size in milliseconds. This is the minimum | |
2012 | duration of time between evaluation events. Windows only elapse | |
2013 | with IO activity. Idle periods extend the most recent window. | |
b351f0c7 | 2014 | |
556910e3 BVA |
2015 | IO Priority |
2016 | ~~~~~~~~~~~ | |
2017 | ||
2018 | A single attribute controls the behavior of the I/O priority cgroup policy, | |
2019 | namely the blkio.prio.class attribute. The following values are accepted for | |
2020 | that attribute: | |
2021 | ||
2022 | no-change | |
2023 | Do not modify the I/O priority class. | |
2024 | ||
2025 | none-to-rt | |
2026 | For requests that do not have an I/O priority class (NONE), | |
2027 | change the I/O priority class into RT. Do not modify | |
2028 | the I/O priority class of other requests. | |
2029 | ||
2030 | restrict-to-be | |
2031 | For requests that do not have an I/O priority class or that have I/O | |
2032 | priority class RT, change it into BE. Do not modify the I/O priority | |
2033 | class of requests that have priority class IDLE. | |
2034 | ||
2035 | idle | |
2036 | Change the I/O priority class of all requests into IDLE, the lowest | |
2037 | I/O priority class. | |
2038 | ||
2039 | The following numerical values are associated with the I/O priority policies: | |
2040 | ||
2041 | +-------------+---+ | |
2042 | | no-change | 0 | | |
2043 | +-------------+---+ | |
2044 | | none-to-rt | 1 | | |
2045 | +-------------+---+ | |
2046 | | rt-to-be | 2 | | |
2047 | +-------------+---+ | |
2048 | | all-to-idle | 3 | | |
2049 | +-------------+---+ | |
2050 | ||
2051 | The numerical value that corresponds to each I/O priority class is as follows: | |
2052 | ||
2053 | +-------------------------------+---+ | |
2054 | | IOPRIO_CLASS_NONE | 0 | | |
2055 | +-------------------------------+---+ | |
2056 | | IOPRIO_CLASS_RT (real-time) | 1 | | |
2057 | +-------------------------------+---+ | |
2058 | | IOPRIO_CLASS_BE (best effort) | 2 | | |
2059 | +-------------------------------+---+ | |
2060 | | IOPRIO_CLASS_IDLE | 3 | | |
2061 | +-------------------------------+---+ | |
2062 | ||
2063 | The algorithm to set the I/O priority class for a request is as follows: | |
2064 | ||
2065 | - Translate the I/O priority class policy into a number. | |
2066 | - Change the request I/O priority class into the maximum of the I/O priority | |
2067 | class policy number and the numerical I/O priority class. | |
2068 | ||
633b11be MCC |
2069 | PID |
2070 | --- | |
20c56e59 HR |
2071 | |
2072 | The process number controller is used to allow a cgroup to stop any | |
2073 | new tasks from being fork()'d or clone()'d after a specified limit is | |
2074 | reached. | |
2075 | ||
2076 | The number of tasks in a cgroup can be exhausted in ways which other | |
2077 | controllers cannot prevent, thus warranting its own controller. For | |
2078 | example, a fork bomb is likely to exhaust the number of tasks before | |
2079 | hitting memory restrictions. | |
2080 | ||
2081 | Note that PIDs used in this controller refer to TIDs, process IDs as | |
2082 | used by the kernel. | |
2083 | ||
2084 | ||
633b11be MCC |
2085 | PID Interface Files |
2086 | ~~~~~~~~~~~~~~~~~~~ | |
20c56e59 HR |
2087 | |
2088 | pids.max | |
312eb712 TK |
2089 | A read-write single value file which exists on non-root |
2090 | cgroups. The default is "max". | |
20c56e59 | 2091 | |
312eb712 | 2092 | Hard limit of number of processes. |
20c56e59 HR |
2093 | |
2094 | pids.current | |
312eb712 | 2095 | A read-only single value file which exists on all cgroups. |
20c56e59 | 2096 | |
312eb712 TK |
2097 | The number of processes currently in the cgroup and its |
2098 | descendants. | |
20c56e59 HR |
2099 | |
2100 | Organisational operations are not blocked by cgroup policies, so it is | |
2101 | possible to have pids.current > pids.max. This can be done by either | |
2102 | setting the limit to be smaller than pids.current, or attaching enough | |
2103 | processes to the cgroup such that pids.current is larger than | |
2104 | pids.max. However, it is not possible to violate a cgroup PID policy | |
2105 | through fork() or clone(). These will return -EAGAIN if the creation | |
2106 | of a new process would cause a cgroup policy to be violated. | |
2107 | ||
2108 | ||
4ec22e9c WL |
2109 | Cpuset |
2110 | ------ | |
2111 | ||
2112 | The "cpuset" controller provides a mechanism for constraining | |
2113 | the CPU and memory node placement of tasks to only the resources | |
2114 | specified in the cpuset interface files in a task's current cgroup. | |
2115 | This is especially valuable on large NUMA systems where placing jobs | |
2116 | on properly sized subsets of the systems with careful processor and | |
2117 | memory placement to reduce cross-node memory access and contention | |
2118 | can improve overall system performance. | |
2119 | ||
2120 | The "cpuset" controller is hierarchical. That means the controller | |
2121 | cannot use CPUs or memory nodes not allowed in its parent. | |
2122 | ||
2123 | ||
2124 | Cpuset Interface Files | |
2125 | ~~~~~~~~~~~~~~~~~~~~~~ | |
2126 | ||
2127 | cpuset.cpus | |
2128 | A read-write multiple values file which exists on non-root | |
2129 | cpuset-enabled cgroups. | |
2130 | ||
2131 | It lists the requested CPUs to be used by tasks within this | |
2132 | cgroup. The actual list of CPUs to be granted, however, is | |
2133 | subjected to constraints imposed by its parent and can differ | |
2134 | from the requested CPUs. | |
2135 | ||
2136 | The CPU numbers are comma-separated numbers or ranges. | |
f3431ba7 | 2137 | For example:: |
4ec22e9c WL |
2138 | |
2139 | # cat cpuset.cpus | |
2140 | 0-4,6,8-10 | |
2141 | ||
2142 | An empty value indicates that the cgroup is using the same | |
2143 | setting as the nearest cgroup ancestor with a non-empty | |
2144 | "cpuset.cpus" or all the available CPUs if none is found. | |
2145 | ||
2146 | The value of "cpuset.cpus" stays constant until the next update | |
2147 | and won't be affected by any CPU hotplug events. | |
2148 | ||
2149 | cpuset.cpus.effective | |
5776cecc | 2150 | A read-only multiple values file which exists on all |
4ec22e9c WL |
2151 | cpuset-enabled cgroups. |
2152 | ||
2153 | It lists the onlined CPUs that are actually granted to this | |
2154 | cgroup by its parent. These CPUs are allowed to be used by | |
2155 | tasks within the current cgroup. | |
2156 | ||
2157 | If "cpuset.cpus" is empty, the "cpuset.cpus.effective" file shows | |
2158 | all the CPUs from the parent cgroup that can be available to | |
2159 | be used by this cgroup. Otherwise, it should be a subset of | |
2160 | "cpuset.cpus" unless none of the CPUs listed in "cpuset.cpus" | |
2161 | can be granted. In this case, it will be treated just like an | |
2162 | empty "cpuset.cpus". | |
2163 | ||
2164 | Its value will be affected by CPU hotplug events. | |
2165 | ||
2166 | cpuset.mems | |
2167 | A read-write multiple values file which exists on non-root | |
2168 | cpuset-enabled cgroups. | |
2169 | ||
2170 | It lists the requested memory nodes to be used by tasks within | |
2171 | this cgroup. The actual list of memory nodes granted, however, | |
2172 | is subjected to constraints imposed by its parent and can differ | |
2173 | from the requested memory nodes. | |
2174 | ||
2175 | The memory node numbers are comma-separated numbers or ranges. | |
f3431ba7 | 2176 | For example:: |
4ec22e9c WL |
2177 | |
2178 | # cat cpuset.mems | |
2179 | 0-1,3 | |
2180 | ||
2181 | An empty value indicates that the cgroup is using the same | |
2182 | setting as the nearest cgroup ancestor with a non-empty | |
2183 | "cpuset.mems" or all the available memory nodes if none | |
2184 | is found. | |
2185 | ||
2186 | The value of "cpuset.mems" stays constant until the next update | |
2187 | and won't be affected by any memory nodes hotplug events. | |
2188 | ||
ee9707e8 WL |
2189 | Setting a non-empty value to "cpuset.mems" causes memory of |
2190 | tasks within the cgroup to be migrated to the designated nodes if | |
2191 | they are currently using memory outside of the designated nodes. | |
2192 | ||
2193 | There is a cost for this memory migration. The migration | |
2194 | may not be complete and some memory pages may be left behind. | |
2195 | So it is recommended that "cpuset.mems" should be set properly | |
2196 | before spawning new tasks into the cpuset. Even if there is | |
2197 | a need to change "cpuset.mems" with active tasks, it shouldn't | |
2198 | be done frequently. | |
2199 | ||
4ec22e9c | 2200 | cpuset.mems.effective |
5776cecc | 2201 | A read-only multiple values file which exists on all |
4ec22e9c WL |
2202 | cpuset-enabled cgroups. |
2203 | ||
2204 | It lists the onlined memory nodes that are actually granted to | |
2205 | this cgroup by its parent. These memory nodes are allowed to | |
2206 | be used by tasks within the current cgroup. | |
2207 | ||
2208 | If "cpuset.mems" is empty, it shows all the memory nodes from the | |
2209 | parent cgroup that will be available to be used by this cgroup. | |
2210 | Otherwise, it should be a subset of "cpuset.mems" unless none of | |
2211 | the memory nodes listed in "cpuset.mems" can be granted. In this | |
2212 | case, it will be treated just like an empty "cpuset.mems". | |
2213 | ||
2214 | Its value will be affected by memory nodes hotplug events. | |
2215 | ||
b1e3aeb1 | 2216 | cpuset.cpus.partition |
90e92f2d WL |
2217 | A read-write single value file which exists on non-root |
2218 | cpuset-enabled cgroups. This flag is owned by the parent cgroup | |
2219 | and is not delegatable. | |
2220 | ||
8a32d0fe | 2221 | It accepts only the following input values when written to. |
90e92f2d | 2222 | |
8cbfdc24 WL |
2223 | ========== ===================================== |
2224 | "member" Non-root member of a partition | |
2225 | "root" Partition root | |
2226 | "isolated" Partition root without load balancing | |
2227 | ========== ===================================== | |
2228 | ||
2229 | The root cgroup is always a partition root and its state | |
2230 | cannot be changed. All other non-root cgroups start out as | |
2231 | "member". | |
2232 | ||
2233 | When set to "root", the current cgroup is the root of a new | |
2234 | partition or scheduling domain that comprises itself and all | |
2235 | its descendants except those that are separate partition roots | |
2236 | themselves and their descendants. | |
2237 | ||
2238 | When set to "isolated", the CPUs in that partition root will | |
2239 | be in an isolated state without any load balancing from the | |
2240 | scheduler. Tasks placed in such a partition with multiple | |
2241 | CPUs should be carefully distributed and bound to each of the | |
2242 | individual CPUs for optimal performance. | |
2243 | ||
2244 | The value shown in "cpuset.cpus.effective" of a partition root | |
2245 | is the CPUs that the partition root can dedicate to a potential | |
2246 | new child partition root. The new child subtracts available | |
2247 | CPUs from its parent "cpuset.cpus.effective". | |
2248 | ||
2249 | A partition root ("root" or "isolated") can be in one of the | |
2250 | two possible states - valid or invalid. An invalid partition | |
2251 | root is in a degraded state where some state information may | |
2252 | be retained, but behaves more like a "member". | |
2253 | ||
2254 | All possible state transitions among "member", "root" and | |
2255 | "isolated" are allowed. | |
2256 | ||
2257 | On read, the "cpuset.cpus.partition" file can show the following | |
2258 | values. | |
2259 | ||
2260 | ============================= ===================================== | |
2261 | "member" Non-root member of a partition | |
2262 | "root" Partition root | |
2263 | "isolated" Partition root without load balancing | |
2264 | "root invalid (<reason>)" Invalid partition root | |
2265 | "isolated invalid (<reason>)" Invalid isolated partition root | |
2266 | ============================= ===================================== | |
2267 | ||
2268 | In the case of an invalid partition root, a descriptive string on | |
2269 | why the partition is invalid is included within parentheses. | |
2270 | ||
2271 | For a partition root to become valid, the following conditions | |
2272 | must be met. | |
2273 | ||
2274 | 1) The "cpuset.cpus" is exclusive with its siblings , i.e. they | |
2275 | are not shared by any of its siblings (exclusivity rule). | |
2276 | 2) The parent cgroup is a valid partition root. | |
2277 | 3) The "cpuset.cpus" is not empty and must contain at least | |
2278 | one of the CPUs from parent's "cpuset.cpus", i.e. they overlap. | |
2279 | 4) The "cpuset.cpus.effective" cannot be empty unless there is | |
2280 | no task associated with this partition. | |
2281 | ||
2282 | External events like hotplug or changes to "cpuset.cpus" can | |
2283 | cause a valid partition root to become invalid and vice versa. | |
2284 | Note that a task cannot be moved to a cgroup with empty | |
2285 | "cpuset.cpus.effective". | |
2286 | ||
2287 | For a valid partition root with the sibling cpu exclusivity | |
2288 | rule enabled, changes made to "cpuset.cpus" that violate the | |
2289 | exclusivity rule will invalidate the partition as well as its | |
dbeb56fe | 2290 | sibling partitions with conflicting cpuset.cpus values. So |
8cbfdc24 WL |
2291 | care must be taking in changing "cpuset.cpus". |
2292 | ||
2293 | A valid non-root parent partition may distribute out all its CPUs | |
2294 | to its child partitions when there is no task associated with it. | |
2295 | ||
2296 | Care must be taken to change a valid partition root to | |
2297 | "member" as all its child partitions, if present, will become | |
2298 | invalid causing disruption to tasks running in those child | |
2299 | partitions. These inactivated partitions could be recovered if | |
2300 | their parent is switched back to a partition root with a proper | |
2301 | set of "cpuset.cpus". | |
2302 | ||
2303 | Poll and inotify events are triggered whenever the state of | |
2304 | "cpuset.cpus.partition" changes. That includes changes caused | |
2305 | by write to "cpuset.cpus.partition", cpu hotplug or other | |
2306 | changes that modify the validity status of the partition. | |
2307 | This will allow user space agents to monitor unexpected changes | |
2308 | to "cpuset.cpus.partition" without the need to do continuous | |
2309 | polling. | |
90e92f2d | 2310 | |
4ec22e9c | 2311 | |
4ad5a321 RG |
2312 | Device controller |
2313 | ----------------- | |
2314 | ||
2315 | Device controller manages access to device files. It includes both | |
2316 | creation of new device files (using mknod), and access to the | |
2317 | existing device files. | |
2318 | ||
2319 | Cgroup v2 device controller has no interface files and is implemented | |
2320 | on top of cgroup BPF. To control access to device files, a user may | |
c0002d11 A |
2321 | create bpf programs of type BPF_PROG_TYPE_CGROUP_DEVICE and attach |
2322 | them to cgroups with BPF_CGROUP_DEVICE flag. On an attempt to access a | |
2323 | device file, corresponding BPF programs will be executed, and depending | |
2324 | on the return value the attempt will succeed or fail with -EPERM. | |
2325 | ||
2326 | A BPF_PROG_TYPE_CGROUP_DEVICE program takes a pointer to the | |
2327 | bpf_cgroup_dev_ctx structure, which describes the device access attempt: | |
2328 | access type (mknod/read/write) and device (type, major and minor numbers). | |
2329 | If the program returns 0, the attempt fails with -EPERM, otherwise it | |
2330 | succeeds. | |
2331 | ||
2332 | An example of BPF_PROG_TYPE_CGROUP_DEVICE program may be found in | |
2333 | tools/testing/selftests/bpf/progs/dev_cgroup.c in the kernel source tree. | |
4ad5a321 RG |
2334 | |
2335 | ||
633b11be MCC |
2336 | RDMA |
2337 | ---- | |
968ebff1 | 2338 | |
9c1e67f9 | 2339 | The "rdma" controller regulates the distribution and accounting of |
aefea466 | 2340 | RDMA resources. |
9c1e67f9 | 2341 | |
633b11be MCC |
2342 | RDMA Interface Files |
2343 | ~~~~~~~~~~~~~~~~~~~~ | |
9c1e67f9 PP |
2344 | |
2345 | rdma.max | |
2346 | A readwrite nested-keyed file that exists for all the cgroups | |
2347 | except root that describes current configured resource limit | |
2348 | for a RDMA/IB device. | |
2349 | ||
2350 | Lines are keyed by device name and are not ordered. | |
2351 | Each line contains space separated resource name and its configured | |
2352 | limit that can be distributed. | |
2353 | ||
2354 | The following nested keys are defined. | |
2355 | ||
633b11be | 2356 | ========== ============================= |
9c1e67f9 PP |
2357 | hca_handle Maximum number of HCA Handles |
2358 | hca_object Maximum number of HCA Objects | |
633b11be | 2359 | ========== ============================= |
9c1e67f9 | 2360 | |
633b11be | 2361 | An example for mlx4 and ocrdma device follows:: |
9c1e67f9 PP |
2362 | |
2363 | mlx4_0 hca_handle=2 hca_object=2000 | |
2364 | ocrdma1 hca_handle=3 hca_object=max | |
2365 | ||
2366 | rdma.current | |
2367 | A read-only file that describes current resource usage. | |
2368 | It exists for all the cgroup except root. | |
2369 | ||
633b11be | 2370 | An example for mlx4 and ocrdma device follows:: |
9c1e67f9 PP |
2371 | |
2372 | mlx4_0 hca_handle=1 hca_object=20 | |
2373 | ocrdma1 hca_handle=1 hca_object=23 | |
2374 | ||
faced7e0 GS |
2375 | HugeTLB |
2376 | ------- | |
2377 | ||
2378 | The HugeTLB controller allows to limit the HugeTLB usage per control group and | |
2379 | enforces the controller limit during page fault. | |
2380 | ||
2381 | HugeTLB Interface Files | |
2382 | ~~~~~~~~~~~~~~~~~~~~~~~ | |
2383 | ||
2384 | hugetlb.<hugepagesize>.current | |
2385 | Show current usage for "hugepagesize" hugetlb. It exists for all | |
2386 | the cgroup except root. | |
2387 | ||
2388 | hugetlb.<hugepagesize>.max | |
2389 | Set/show the hard limit of "hugepagesize" hugetlb usage. | |
2390 | The default value is "max". It exists for all the cgroup except root. | |
2391 | ||
2392 | hugetlb.<hugepagesize>.events | |
2393 | A read-only flat-keyed file which exists on non-root cgroups. | |
2394 | ||
2395 | max | |
2396 | The number of allocation failure due to HugeTLB limit | |
2397 | ||
2398 | hugetlb.<hugepagesize>.events.local | |
2399 | Similar to hugetlb.<hugepagesize>.events but the fields in the file | |
2400 | are local to the cgroup i.e. not hierarchical. The file modified event | |
2401 | generated on this file reflects only the local events. | |
9c1e67f9 | 2402 | |
f4776199 MA |
2403 | hugetlb.<hugepagesize>.numa_stat |
2404 | Similar to memory.numa_stat, it shows the numa information of the | |
2405 | hugetlb pages of <hugepagesize> in this cgroup. Only active in | |
2406 | use hugetlb pages are included. The per-node values are in bytes. | |
2407 | ||
633b11be MCC |
2408 | Misc |
2409 | ---- | |
63f1ca59 | 2410 | |
25259fc9 VS |
2411 | The Miscellaneous cgroup provides the resource limiting and tracking |
2412 | mechanism for the scalar resources which cannot be abstracted like the other | |
2413 | cgroup resources. Controller is enabled by the CONFIG_CGROUP_MISC config | |
2414 | option. | |
2415 | ||
2416 | A resource can be added to the controller via enum misc_res_type{} in the | |
2417 | include/linux/misc_cgroup.h file and the corresponding name via misc_res_name[] | |
2418 | in the kernel/cgroup/misc.c file. Provider of the resource must set its | |
2419 | capacity prior to using the resource by calling misc_cg_set_capacity(). | |
2420 | ||
2421 | Once a capacity is set then the resource usage can be updated using charge and | |
2422 | uncharge APIs. All of the APIs to interact with misc controller are in | |
2423 | include/linux/misc_cgroup.h. | |
2424 | ||
2425 | Misc Interface Files | |
2426 | ~~~~~~~~~~~~~~~~~~~~ | |
2427 | ||
2428 | Miscellaneous controller provides 3 interface files. If two misc resources (res_a and res_b) are registered then: | |
2429 | ||
2430 | misc.capacity | |
2431 | A read-only flat-keyed file shown only in the root cgroup. It shows | |
2432 | miscellaneous scalar resources available on the platform along with | |
2433 | their quantities:: | |
2434 | ||
2435 | $ cat misc.capacity | |
2436 | res_a 50 | |
2437 | res_b 10 | |
2438 | ||
2439 | misc.current | |
2440 | A read-only flat-keyed file shown in the non-root cgroups. It shows | |
2441 | the current usage of the resources in the cgroup and its children.:: | |
2442 | ||
2443 | $ cat misc.current | |
2444 | res_a 3 | |
2445 | res_b 0 | |
2446 | ||
2447 | misc.max | |
2448 | A read-write flat-keyed file shown in the non root cgroups. Allowed | |
2449 | maximum usage of the resources in the cgroup and its children.:: | |
2450 | ||
2451 | $ cat misc.max | |
2452 | res_a max | |
2453 | res_b 4 | |
2454 | ||
2455 | Limit can be set by:: | |
2456 | ||
2457 | # echo res_a 1 > misc.max | |
2458 | ||
2459 | Limit can be set to max by:: | |
2460 | ||
2461 | # echo res_a max > misc.max | |
2462 | ||
2463 | Limits can be set higher than the capacity value in the misc.capacity | |
2464 | file. | |
2465 | ||
4b53bb87 CX |
2466 | misc.events |
2467 | A read-only flat-keyed file which exists on non-root cgroups. The | |
2468 | following entries are defined. Unless specified otherwise, a value | |
2469 | change in this file generates a file modified event. All fields in | |
2470 | this file are hierarchical. | |
2471 | ||
2472 | max | |
2473 | The number of times the cgroup's resource usage was | |
2474 | about to go over the max boundary. | |
2475 | ||
25259fc9 VS |
2476 | Migration and Ownership |
2477 | ~~~~~~~~~~~~~~~~~~~~~~~ | |
2478 | ||
2479 | A miscellaneous scalar resource is charged to the cgroup in which it is used | |
2480 | first, and stays charged to that cgroup until that resource is freed. Migrating | |
2481 | a process to a different cgroup does not move the charge to the destination | |
2482 | cgroup where the process has moved. | |
2483 | ||
2484 | Others | |
2485 | ------ | |
2486 | ||
633b11be MCC |
2487 | perf_event |
2488 | ~~~~~~~~~~ | |
968ebff1 TH |
2489 | |
2490 | perf_event controller, if not mounted on a legacy hierarchy, is | |
2491 | automatically enabled on the v2 hierarchy so that perf events can | |
2492 | always be filtered by cgroup v2 path. The controller can still be | |
2493 | moved to a legacy hierarchy after v2 hierarchy is populated. | |
2494 | ||
2495 | ||
c4e0842b MS |
2496 | Non-normative information |
2497 | ------------------------- | |
2498 | ||
2499 | This section contains information that isn't considered to be a part of | |
2500 | the stable kernel API and so is subject to change. | |
2501 | ||
2502 | ||
2503 | CPU controller root cgroup process behaviour | |
2504 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
2505 | ||
2506 | When distributing CPU cycles in the root cgroup each thread in this | |
2507 | cgroup is treated as if it was hosted in a separate child cgroup of the | |
2508 | root cgroup. This child cgroup weight is dependent on its thread nice | |
2509 | level. | |
2510 | ||
2511 | For details of this mapping see sched_prio_to_weight array in | |
2512 | kernel/sched/core.c file (values from this array should be scaled | |
2513 | appropriately so the neutral - nice 0 - value is 100 instead of 1024). | |
2514 | ||
2515 | ||
2516 | IO controller root cgroup process behaviour | |
2517 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
2518 | ||
2519 | Root cgroup processes are hosted in an implicit leaf child node. | |
2520 | When distributing IO resources this implicit child node is taken into | |
2521 | account as if it was a normal child cgroup of the root cgroup with a | |
2522 | weight value of 200. | |
2523 | ||
2524 | ||
633b11be MCC |
2525 | Namespace |
2526 | ========= | |
d4021f6c | 2527 | |
633b11be MCC |
2528 | Basics |
2529 | ------ | |
d4021f6c SH |
2530 | |
2531 | cgroup namespace provides a mechanism to virtualize the view of the | |
2532 | "/proc/$PID/cgroup" file and cgroup mounts. The CLONE_NEWCGROUP clone | |
2533 | flag can be used with clone(2) and unshare(2) to create a new cgroup | |
2534 | namespace. The process running inside the cgroup namespace will have | |
2535 | its "/proc/$PID/cgroup" output restricted to cgroupns root. The | |
2536 | cgroupns root is the cgroup of the process at the time of creation of | |
2537 | the cgroup namespace. | |
2538 | ||
2539 | Without cgroup namespace, the "/proc/$PID/cgroup" file shows the | |
2540 | complete path of the cgroup of a process. In a container setup where | |
2541 | a set of cgroups and namespaces are intended to isolate processes the | |
2542 | "/proc/$PID/cgroup" file may leak potential system level information | |
7361ec68 | 2543 | to the isolated processes. For example:: |
d4021f6c SH |
2544 | |
2545 | # cat /proc/self/cgroup | |
2546 | 0::/batchjobs/container_id1 | |
2547 | ||
2548 | The path '/batchjobs/container_id1' can be considered as system-data | |
2549 | and undesirable to expose to the isolated processes. cgroup namespace | |
2550 | can be used to restrict visibility of this path. For example, before | |
633b11be | 2551 | creating a cgroup namespace, one would see:: |
d4021f6c SH |
2552 | |
2553 | # ls -l /proc/self/ns/cgroup | |
2554 | lrwxrwxrwx 1 root root 0 2014-07-15 10:37 /proc/self/ns/cgroup -> cgroup:[4026531835] | |
2555 | # cat /proc/self/cgroup | |
2556 | 0::/batchjobs/container_id1 | |
2557 | ||
633b11be | 2558 | After unsharing a new namespace, the view changes:: |
d4021f6c SH |
2559 | |
2560 | # ls -l /proc/self/ns/cgroup | |
2561 | lrwxrwxrwx 1 root root 0 2014-07-15 10:35 /proc/self/ns/cgroup -> cgroup:[4026532183] | |
2562 | # cat /proc/self/cgroup | |
2563 | 0::/ | |
2564 | ||
2565 | When some thread from a multi-threaded process unshares its cgroup | |
2566 | namespace, the new cgroupns gets applied to the entire process (all | |
2567 | the threads). This is natural for the v2 hierarchy; however, for the | |
2568 | legacy hierarchies, this may be unexpected. | |
2569 | ||
2570 | A cgroup namespace is alive as long as there are processes inside or | |
2571 | mounts pinning it. When the last usage goes away, the cgroup | |
2572 | namespace is destroyed. The cgroupns root and the actual cgroups | |
2573 | remain. | |
2574 | ||
2575 | ||
633b11be MCC |
2576 | The Root and Views |
2577 | ------------------ | |
d4021f6c SH |
2578 | |
2579 | The 'cgroupns root' for a cgroup namespace is the cgroup in which the | |
2580 | process calling unshare(2) is running. For example, if a process in | |
2581 | /batchjobs/container_id1 cgroup calls unshare, cgroup | |
2582 | /batchjobs/container_id1 becomes the cgroupns root. For the | |
2583 | init_cgroup_ns, this is the real root ('/') cgroup. | |
2584 | ||
2585 | The cgroupns root cgroup does not change even if the namespace creator | |
633b11be | 2586 | process later moves to a different cgroup:: |
d4021f6c SH |
2587 | |
2588 | # ~/unshare -c # unshare cgroupns in some cgroup | |
2589 | # cat /proc/self/cgroup | |
2590 | 0::/ | |
2591 | # mkdir sub_cgrp_1 | |
2592 | # echo 0 > sub_cgrp_1/cgroup.procs | |
2593 | # cat /proc/self/cgroup | |
2594 | 0::/sub_cgrp_1 | |
2595 | ||
2596 | Each process gets its namespace-specific view of "/proc/$PID/cgroup" | |
2597 | ||
2598 | Processes running inside the cgroup namespace will be able to see | |
2599 | cgroup paths (in /proc/self/cgroup) only inside their root cgroup. | |
633b11be | 2600 | From within an unshared cgroupns:: |
d4021f6c SH |
2601 | |
2602 | # sleep 100000 & | |
2603 | [1] 7353 | |
2604 | # echo 7353 > sub_cgrp_1/cgroup.procs | |
2605 | # cat /proc/7353/cgroup | |
2606 | 0::/sub_cgrp_1 | |
2607 | ||
2608 | From the initial cgroup namespace, the real cgroup path will be | |
633b11be | 2609 | visible:: |
d4021f6c SH |
2610 | |
2611 | $ cat /proc/7353/cgroup | |
2612 | 0::/batchjobs/container_id1/sub_cgrp_1 | |
2613 | ||
2614 | From a sibling cgroup namespace (that is, a namespace rooted at a | |
2615 | different cgroup), the cgroup path relative to its own cgroup | |
2616 | namespace root will be shown. For instance, if PID 7353's cgroup | |
633b11be | 2617 | namespace root is at '/batchjobs/container_id2', then it will see:: |
d4021f6c SH |
2618 | |
2619 | # cat /proc/7353/cgroup | |
2620 | 0::/../container_id2/sub_cgrp_1 | |
2621 | ||
2622 | Note that the relative path always starts with '/' to indicate that | |
2623 | its relative to the cgroup namespace root of the caller. | |
2624 | ||
2625 | ||
633b11be MCC |
2626 | Migration and setns(2) |
2627 | ---------------------- | |
d4021f6c SH |
2628 | |
2629 | Processes inside a cgroup namespace can move into and out of the | |
2630 | namespace root if they have proper access to external cgroups. For | |
2631 | example, from inside a namespace with cgroupns root at | |
2632 | /batchjobs/container_id1, and assuming that the global hierarchy is | |
633b11be | 2633 | still accessible inside cgroupns:: |
d4021f6c SH |
2634 | |
2635 | # cat /proc/7353/cgroup | |
2636 | 0::/sub_cgrp_1 | |
2637 | # echo 7353 > batchjobs/container_id2/cgroup.procs | |
2638 | # cat /proc/7353/cgroup | |
2639 | 0::/../container_id2 | |
2640 | ||
2641 | Note that this kind of setup is not encouraged. A task inside cgroup | |
2642 | namespace should only be exposed to its own cgroupns hierarchy. | |
2643 | ||
2644 | setns(2) to another cgroup namespace is allowed when: | |
2645 | ||
2646 | (a) the process has CAP_SYS_ADMIN against its current user namespace | |
2647 | (b) the process has CAP_SYS_ADMIN against the target cgroup | |
2648 | namespace's userns | |
2649 | ||
2650 | No implicit cgroup changes happen with attaching to another cgroup | |
2651 | namespace. It is expected that the someone moves the attaching | |
2652 | process under the target cgroup namespace root. | |
2653 | ||
2654 | ||
633b11be MCC |
2655 | Interaction with Other Namespaces |
2656 | --------------------------------- | |
d4021f6c SH |
2657 | |
2658 | Namespace specific cgroup hierarchy can be mounted by a process | |
633b11be | 2659 | running inside a non-init cgroup namespace:: |
d4021f6c SH |
2660 | |
2661 | # mount -t cgroup2 none $MOUNT_POINT | |
2662 | ||
2663 | This will mount the unified cgroup hierarchy with cgroupns root as the | |
2664 | filesystem root. The process needs CAP_SYS_ADMIN against its user and | |
2665 | mount namespaces. | |
2666 | ||
2667 | The virtualization of /proc/self/cgroup file combined with restricting | |
2668 | the view of cgroup hierarchy by namespace-private cgroupfs mount | |
2669 | provides a properly isolated cgroup view inside the container. | |
2670 | ||
2671 | ||
633b11be MCC |
2672 | Information on Kernel Programming |
2673 | ================================= | |
6c292092 TH |
2674 | |
2675 | This section contains kernel programming information in the areas | |
2676 | where interacting with cgroup is necessary. cgroup core and | |
2677 | controllers are not covered. | |
2678 | ||
2679 | ||
633b11be MCC |
2680 | Filesystem Support for Writeback |
2681 | -------------------------------- | |
6c292092 TH |
2682 | |
2683 | A filesystem can support cgroup writeback by updating | |
2684 | address_space_operations->writepage[s]() to annotate bio's using the | |
2685 | following two functions. | |
2686 | ||
2687 | wbc_init_bio(@wbc, @bio) | |
6c292092 | 2688 | Should be called for each bio carrying writeback data and |
fd42df30 DZ |
2689 | associates the bio with the inode's owner cgroup and the |
2690 | corresponding request queue. This must be called after | |
2691 | a queue (device) has been associated with the bio and | |
2692 | before submission. | |
6c292092 | 2693 | |
34e51a5e | 2694 | wbc_account_cgroup_owner(@wbc, @page, @bytes) |
6c292092 TH |
2695 | Should be called for each data segment being written out. |
2696 | While this function doesn't care exactly when it's called | |
2697 | during the writeback session, it's the easiest and most | |
2698 | natural to call it as data segments are added to a bio. | |
2699 | ||
2700 | With writeback bio's annotated, cgroup support can be enabled per | |
2701 | super_block by setting SB_I_CGROUPWB in ->s_iflags. This allows for | |
2702 | selective disabling of cgroup writeback support which is helpful when | |
2703 | certain filesystem features, e.g. journaled data mode, are | |
2704 | incompatible. | |
2705 | ||
2706 | wbc_init_bio() binds the specified bio to its cgroup. Depending on | |
2707 | the configuration, the bio may be executed at a lower priority and if | |
2708 | the writeback session is holding shared resources, e.g. a journal | |
2709 | entry, may lead to priority inversion. There is no one easy solution | |
2710 | for the problem. Filesystems can try to work around specific problem | |
fd42df30 | 2711 | cases by skipping wbc_init_bio() and using bio_associate_blkg() |
6c292092 TH |
2712 | directly. |
2713 | ||
2714 | ||
633b11be MCC |
2715 | Deprecated v1 Core Features |
2716 | =========================== | |
6c292092 TH |
2717 | |
2718 | - Multiple hierarchies including named ones are not supported. | |
2719 | ||
5136f636 | 2720 | - All v1 mount options are not supported. |
6c292092 TH |
2721 | |
2722 | - The "tasks" file is removed and "cgroup.procs" is not sorted. | |
2723 | ||
2724 | - "cgroup.clone_children" is removed. | |
2725 | ||
2726 | - /proc/cgroups is meaningless for v2. Use "cgroup.controllers" file | |
2727 | at the root instead. | |
2728 | ||
2729 | ||
633b11be MCC |
2730 | Issues with v1 and Rationales for v2 |
2731 | ==================================== | |
6c292092 | 2732 | |
633b11be MCC |
2733 | Multiple Hierarchies |
2734 | -------------------- | |
6c292092 TH |
2735 | |
2736 | cgroup v1 allowed an arbitrary number of hierarchies and each | |
2737 | hierarchy could host any number of controllers. While this seemed to | |
2738 | provide a high level of flexibility, it wasn't useful in practice. | |
2739 | ||
2740 | For example, as there is only one instance of each controller, utility | |
2741 | type controllers such as freezer which can be useful in all | |
2742 | hierarchies could only be used in one. The issue is exacerbated by | |
2743 | the fact that controllers couldn't be moved to another hierarchy once | |
2744 | hierarchies were populated. Another issue was that all controllers | |
2745 | bound to a hierarchy were forced to have exactly the same view of the | |
2746 | hierarchy. It wasn't possible to vary the granularity depending on | |
2747 | the specific controller. | |
2748 | ||
2749 | In practice, these issues heavily limited which controllers could be | |
2750 | put on the same hierarchy and most configurations resorted to putting | |
2751 | each controller on its own hierarchy. Only closely related ones, such | |
2752 | as the cpu and cpuacct controllers, made sense to be put on the same | |
2753 | hierarchy. This often meant that userland ended up managing multiple | |
2754 | similar hierarchies repeating the same steps on each hierarchy | |
2755 | whenever a hierarchy management operation was necessary. | |
2756 | ||
2757 | Furthermore, support for multiple hierarchies came at a steep cost. | |
2758 | It greatly complicated cgroup core implementation but more importantly | |
2759 | the support for multiple hierarchies restricted how cgroup could be | |
2760 | used in general and what controllers was able to do. | |
2761 | ||
2762 | There was no limit on how many hierarchies there might be, which meant | |
2763 | that a thread's cgroup membership couldn't be described in finite | |
2764 | length. The key might contain any number of entries and was unlimited | |
2765 | in length, which made it highly awkward to manipulate and led to | |
2766 | addition of controllers which existed only to identify membership, | |
2767 | which in turn exacerbated the original problem of proliferating number | |
2768 | of hierarchies. | |
2769 | ||
2770 | Also, as a controller couldn't have any expectation regarding the | |
2771 | topologies of hierarchies other controllers might be on, each | |
2772 | controller had to assume that all other controllers were attached to | |
2773 | completely orthogonal hierarchies. This made it impossible, or at | |
2774 | least very cumbersome, for controllers to cooperate with each other. | |
2775 | ||
2776 | In most use cases, putting controllers on hierarchies which are | |
2777 | completely orthogonal to each other isn't necessary. What usually is | |
2778 | called for is the ability to have differing levels of granularity | |
2779 | depending on the specific controller. In other words, hierarchy may | |
2780 | be collapsed from leaf towards root when viewed from specific | |
2781 | controllers. For example, a given configuration might not care about | |
2782 | how memory is distributed beyond a certain level while still wanting | |
2783 | to control how CPU cycles are distributed. | |
2784 | ||
2785 | ||
633b11be MCC |
2786 | Thread Granularity |
2787 | ------------------ | |
6c292092 TH |
2788 | |
2789 | cgroup v1 allowed threads of a process to belong to different cgroups. | |
2790 | This didn't make sense for some controllers and those controllers | |
2791 | ended up implementing different ways to ignore such situations but | |
2792 | much more importantly it blurred the line between API exposed to | |
2793 | individual applications and system management interface. | |
2794 | ||
2795 | Generally, in-process knowledge is available only to the process | |
2796 | itself; thus, unlike service-level organization of processes, | |
2797 | categorizing threads of a process requires active participation from | |
2798 | the application which owns the target process. | |
2799 | ||
2800 | cgroup v1 had an ambiguously defined delegation model which got abused | |
2801 | in combination with thread granularity. cgroups were delegated to | |
2802 | individual applications so that they can create and manage their own | |
2803 | sub-hierarchies and control resource distributions along them. This | |
2804 | effectively raised cgroup to the status of a syscall-like API exposed | |
2805 | to lay programs. | |
2806 | ||
2807 | First of all, cgroup has a fundamentally inadequate interface to be | |
2808 | exposed this way. For a process to access its own knobs, it has to | |
2809 | extract the path on the target hierarchy from /proc/self/cgroup, | |
2810 | construct the path by appending the name of the knob to the path, open | |
2811 | and then read and/or write to it. This is not only extremely clunky | |
2812 | and unusual but also inherently racy. There is no conventional way to | |
2813 | define transaction across the required steps and nothing can guarantee | |
2814 | that the process would actually be operating on its own sub-hierarchy. | |
2815 | ||
2816 | cgroup controllers implemented a number of knobs which would never be | |
2817 | accepted as public APIs because they were just adding control knobs to | |
2818 | system-management pseudo filesystem. cgroup ended up with interface | |
2819 | knobs which were not properly abstracted or refined and directly | |
2820 | revealed kernel internal details. These knobs got exposed to | |
2821 | individual applications through the ill-defined delegation mechanism | |
2822 | effectively abusing cgroup as a shortcut to implementing public APIs | |
2823 | without going through the required scrutiny. | |
2824 | ||
2825 | This was painful for both userland and kernel. Userland ended up with | |
2826 | misbehaving and poorly abstracted interfaces and kernel exposing and | |
2827 | locked into constructs inadvertently. | |
2828 | ||
2829 | ||
633b11be MCC |
2830 | Competition Between Inner Nodes and Threads |
2831 | ------------------------------------------- | |
6c292092 TH |
2832 | |
2833 | cgroup v1 allowed threads to be in any cgroups which created an | |
2834 | interesting problem where threads belonging to a parent cgroup and its | |
2835 | children cgroups competed for resources. This was nasty as two | |
2836 | different types of entities competed and there was no obvious way to | |
2837 | settle it. Different controllers did different things. | |
2838 | ||
2839 | The cpu controller considered threads and cgroups as equivalents and | |
2840 | mapped nice levels to cgroup weights. This worked for some cases but | |
2841 | fell flat when children wanted to be allocated specific ratios of CPU | |
2842 | cycles and the number of internal threads fluctuated - the ratios | |
2843 | constantly changed as the number of competing entities fluctuated. | |
2844 | There also were other issues. The mapping from nice level to weight | |
2845 | wasn't obvious or universal, and there were various other knobs which | |
2846 | simply weren't available for threads. | |
2847 | ||
2848 | The io controller implicitly created a hidden leaf node for each | |
2849 | cgroup to host the threads. The hidden leaf had its own copies of all | |
633b11be | 2850 | the knobs with ``leaf_`` prefixed. While this allowed equivalent |
6c292092 TH |
2851 | control over internal threads, it was with serious drawbacks. It |
2852 | always added an extra layer of nesting which wouldn't be necessary | |
2853 | otherwise, made the interface messy and significantly complicated the | |
2854 | implementation. | |
2855 | ||
2856 | The memory controller didn't have a way to control what happened | |
2857 | between internal tasks and child cgroups and the behavior was not | |
2858 | clearly defined. There were attempts to add ad-hoc behaviors and | |
2859 | knobs to tailor the behavior to specific workloads which would have | |
2860 | led to problems extremely difficult to resolve in the long term. | |
2861 | ||
2862 | Multiple controllers struggled with internal tasks and came up with | |
2863 | different ways to deal with it; unfortunately, all the approaches were | |
2864 | severely flawed and, furthermore, the widely different behaviors | |
2865 | made cgroup as a whole highly inconsistent. | |
2866 | ||
2867 | This clearly is a problem which needs to be addressed from cgroup core | |
2868 | in a uniform way. | |
2869 | ||
2870 | ||
633b11be MCC |
2871 | Other Interface Issues |
2872 | ---------------------- | |
6c292092 TH |
2873 | |
2874 | cgroup v1 grew without oversight and developed a large number of | |
2875 | idiosyncrasies and inconsistencies. One issue on the cgroup core side | |
2876 | was how an empty cgroup was notified - a userland helper binary was | |
2877 | forked and executed for each event. The event delivery wasn't | |
2878 | recursive or delegatable. The limitations of the mechanism also led | |
2879 | to in-kernel event delivery filtering mechanism further complicating | |
2880 | the interface. | |
2881 | ||
2882 | Controller interfaces were problematic too. An extreme example is | |
2883 | controllers completely ignoring hierarchical organization and treating | |
2884 | all cgroups as if they were all located directly under the root | |
2885 | cgroup. Some controllers exposed a large amount of inconsistent | |
2886 | implementation details to userland. | |
2887 | ||
2888 | There also was no consistency across controllers. When a new cgroup | |
2889 | was created, some controllers defaulted to not imposing extra | |
2890 | restrictions while others disallowed any resource usage until | |
2891 | explicitly configured. Configuration knobs for the same type of | |
2892 | control used widely differing naming schemes and formats. Statistics | |
2893 | and information knobs were named arbitrarily and used different | |
2894 | formats and units even in the same controller. | |
2895 | ||
2896 | cgroup v2 establishes common conventions where appropriate and updates | |
2897 | controllers so that they expose minimal and consistent interfaces. | |
2898 | ||
2899 | ||
633b11be MCC |
2900 | Controller Issues and Remedies |
2901 | ------------------------------ | |
6c292092 | 2902 | |
633b11be MCC |
2903 | Memory |
2904 | ~~~~~~ | |
6c292092 TH |
2905 | |
2906 | The original lower boundary, the soft limit, is defined as a limit | |
2907 | that is per default unset. As a result, the set of cgroups that | |
2908 | global reclaim prefers is opt-in, rather than opt-out. The costs for | |
2909 | optimizing these mostly negative lookups are so high that the | |
2910 | implementation, despite its enormous size, does not even provide the | |
2911 | basic desirable behavior. First off, the soft limit has no | |
2912 | hierarchical meaning. All configured groups are organized in a global | |
2913 | rbtree and treated like equal peers, regardless where they are located | |
2914 | in the hierarchy. This makes subtree delegation impossible. Second, | |
2915 | the soft limit reclaim pass is so aggressive that it not just | |
2916 | introduces high allocation latencies into the system, but also impacts | |
2917 | system performance due to overreclaim, to the point where the feature | |
2918 | becomes self-defeating. | |
2919 | ||
2920 | The memory.low boundary on the other hand is a top-down allocated | |
9783aa99 CD |
2921 | reserve. A cgroup enjoys reclaim protection when it's within its |
2922 | effective low, which makes delegation of subtrees possible. It also | |
2923 | enjoys having reclaim pressure proportional to its overage when | |
2924 | above its effective low. | |
6c292092 TH |
2925 | |
2926 | The original high boundary, the hard limit, is defined as a strict | |
2927 | limit that can not budge, even if the OOM killer has to be called. | |
2928 | But this generally goes against the goal of making the most out of the | |
2929 | available memory. The memory consumption of workloads varies during | |
2930 | runtime, and that requires users to overcommit. But doing that with a | |
2931 | strict upper limit requires either a fairly accurate prediction of the | |
2932 | working set size or adding slack to the limit. Since working set size | |
2933 | estimation is hard and error prone, and getting it wrong results in | |
2934 | OOM kills, most users tend to err on the side of a looser limit and | |
2935 | end up wasting precious resources. | |
2936 | ||
2937 | The memory.high boundary on the other hand can be set much more | |
2938 | conservatively. When hit, it throttles allocations by forcing them | |
2939 | into direct reclaim to work off the excess, but it never invokes the | |
2940 | OOM killer. As a result, a high boundary that is chosen too | |
2941 | aggressively will not terminate the processes, but instead it will | |
2942 | lead to gradual performance degradation. The user can monitor this | |
2943 | and make corrections until the minimal memory footprint that still | |
2944 | gives acceptable performance is found. | |
2945 | ||
2946 | In extreme cases, with many concurrent allocations and a complete | |
2947 | breakdown of reclaim progress within the group, the high boundary can | |
2948 | be exceeded. But even then it's mostly better to satisfy the | |
2949 | allocation from the slack available in other groups or the rest of the | |
2950 | system than killing the group. Otherwise, memory.max is there to | |
2951 | limit this type of spillover and ultimately contain buggy or even | |
2952 | malicious applications. | |
3e24b19d | 2953 | |
b6e6edcf JW |
2954 | Setting the original memory.limit_in_bytes below the current usage was |
2955 | subject to a race condition, where concurrent charges could cause the | |
2956 | limit setting to fail. memory.max on the other hand will first set the | |
2957 | limit to prevent new charges, and then reclaim and OOM kill until the | |
2958 | new limit is met - or the task writing to memory.max is killed. | |
2959 | ||
3e24b19d VD |
2960 | The combined memory+swap accounting and limiting is replaced by real |
2961 | control over swap space. | |
2962 | ||
2963 | The main argument for a combined memory+swap facility in the original | |
2964 | cgroup design was that global or parental pressure would always be | |
2965 | able to swap all anonymous memory of a child group, regardless of the | |
2966 | child's own (possibly untrusted) configuration. However, untrusted | |
2967 | groups can sabotage swapping by other means - such as referencing its | |
2968 | anonymous memory in a tight loop - and an admin can not assume full | |
2969 | swappability when overcommitting untrusted jobs. | |
2970 | ||
2971 | For trusted jobs, on the other hand, a combined counter is not an | |
2972 | intuitive userspace interface, and it flies in the face of the idea | |
2973 | that cgroup controllers should account and limit specific physical | |
2974 | resources. Swap space is a resource like all others in the system, | |
2975 | and that's why unified hierarchy allows distributing it separately. |