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