Lines Matching refs:cgroup
11 conventions of cgroup v2. It describes all userland-visible aspects
12 of cgroup including core and specific controller behaviors. All
14 v1 is available under :ref:`Documentation/admin-guide/cgroup-v1/index.rst <cgroup-v1>`.
20 1-2. What is cgroup?
70 5.9-1 Miscellaneous cgroup Interface Files
75 5-N-1. CPU controller root cgroup process behaviour
76 5-N-2. IO controller root cgroup process behaviour
100 "cgroup" stands for "control group" and is never capitalized. The
102 qualifier as in "cgroup controllers". When explicitly referring to
106 What is cgroup?
109 cgroup is a mechanism to organize processes hierarchically and
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
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
124 to another cgroup. Migration of a process doesn't affect already
128 disabled selectively on a cgroup. All controller behaviors are
129 hierarchical - if a controller is enabled on a cgroup, it affects all
131 sub-hierarchy of the cgroup. When a controller is enabled on a nested
132 cgroup, it always restricts the resource distribution further. The
143 Unlike v1, cgroup v2 has only single hierarchy. The cgroup v2
156 is no longer referenced in its current hierarchy. Because per-cgroup
173 automount the v1 cgroup filesystem and so hijack all controllers
178 cgroup v2 currently supports the following mount options.
181 Consider cgroup namespaces as delegation boundaries. This
188 Only populate memory.events with data for the current cgroup,
212 Initially, only the root cgroup exists to which all processes belong.
213 A child cgroup can be created by creating a sub-directory::
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
222 another cgroup and then back or the PID got recycled while reading.
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
231 cgroup that the forking process belongs to at the time of the
232 operation. After exit, a process stays associated with the cgroup
234 zombie process does not appear in "cgroup.procs" and thus can't be
235 moved to another cgroup.
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
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
249 # cat /proc/842/cgroup
251 0::/test-cgroup/test-cgroup-nested
253 If the process becomes a zombie and the cgroup it was associated with
256 # cat /proc/842/cgroup
258 0::/test-cgroup/test-cgroup-nested (deleted)
264 cgroup v2 supports thread granularity for a subset of controllers to
267 process belong to the same cgroup, which also serves as the resource
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
287 As the threaded domain cgroup hosts all the domain resource
291 root cgroup is not subject to no internal process constraint, it can
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
297 or a threaded cgroup.
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
303 # echo threaded > cgroup.type
305 Once threaded, the cgroup can't be made a domain again. To enable the
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.
315 Topology-wise, a cgroup can be in an invalid state. Please consider
322 threaded cgroup. "cgroup.type" file will report "domain (invalid)" in
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.
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
340 The threaded domain cgroup serves as the resource domain for the whole
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
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.
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.
356 between threads in a non-leaf cgroup and its child cgroups. Each
363 Each non-root cgroup has a "cgroup.events" file which contains
364 "populated" field indicating whether the cgroup's sub-hierarchy has
366 the cgroup and its descendants; otherwise, 1. poll and [id]notify
372 in each cgroup::
379 file modified events will be generated on the "cgroup.events" files of
389 Each cgroup has a "cgroup.controllers" file which lists all
390 controllers available for the cgroup to enable::
392 # cat cgroup.controllers
396 disabled by writing to the "cgroup.subtree_control" file::
398 # echo "+cpu +memory -io" > cgroup.subtree_control
400 Only controllers which are listed in "cgroup.controllers" can be
405 Enabling a controller in a cgroup indicates that the distribution of
419 the cgroup's children, enabling it creates the controller's interface
425 "cgroup." are owned by the parent rather than the cgroup itself.
431 Resources are distributed top-down and a cgroup can further distribute
433 parent. This means that all non-root "cgroup.subtree_control" files
435 "cgroup.subtree_control" file. A controller can be enabled only if
446 controllers enabled in their "cgroup.subtree_control" files.
453 The root cgroup is exempt from this restriction. Root contains
456 controllers. How resource consumption in the root cgroup is governed
462 enabled controller in the cgroup's "cgroup.subtree_control". This is
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"
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.
480 cgroup namespace on namespace creation.
486 kernel rejects writes to all files other than "cgroup.procs" and
487 "cgroup.subtree_control" on a namespace root from inside the
498 Currently, cgroup doesn't impose any restrictions on the number of
511 to migrate a target process into a cgroup by writing its PID to the
512 "cgroup.procs" file.
514 - The writer must have write access to the "cgroup.procs" file.
516 - The writer must have write access to the "cgroup.procs" file of the
528 ~ cgroup ~ \ C01
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
559 should be assigned to a cgroup according to the system's logical and
568 Interface files for a cgroup and its children cgroups occupy the same
572 All cgroup core interface files are prefixed with "cgroup." and each
580 cgroup doesn't do anything to prevent name collisions and it's the
587 cgroup controllers implement several resource distribution schemes
627 "io.max" limits the maximum BPS and/or IOPS that a cgroup can consume
634 A cgroup is protected upto the configured amount of the resource
655 A cgroup is exclusively allocated a certain amount of a finite
719 - The root cgroup should be exempt from resource control and thus
757 # cat cgroup-example-interface-file
763 # echo 125 > cgroup-example-interface-file
767 # echo "default 125" > cgroup-example-interface-file
771 # echo "8:16 170" > cgroup-example-interface-file
775 # echo "8:0 default" > cgroup-example-interface-file
776 # cat cgroup-example-interface-file
789 All cgroup core files are prefixed with "cgroup."
791 cgroup.type
795 When read, it indicates the current type of the cgroup, which
798 - "domain" : A normal valid domain cgroup.
800 - "domain threaded" : A threaded domain cgroup which is
803 - "domain invalid" : A cgroup which is in an invalid state.
805 be allowed to become a threaded cgroup.
807 - "threaded" : A threaded cgroup which is a member of a
810 A cgroup can be turned into a threaded cgroup by writing
813 cgroup.procs
818 the cgroup one-per-line. The PIDs are not ordered and the
820 to another cgroup and then back or the PID got recycled while
824 the PID to the cgroup. The writer should match all of the
827 - It must have write access to the "cgroup.procs" file.
829 - It must have write access to the "cgroup.procs" file of the
835 In a threaded cgroup, reading this file fails with EOPNOTSUPP
837 supported and moves every thread of the process to the cgroup.
839 cgroup.threads
844 the cgroup one-per-line. The TIDs are not ordered and the
846 another cgroup and then back or the TID got recycled while
850 TID to the cgroup. The writer should match all of the
853 - It must have write access to the "cgroup.threads" file.
855 - The cgroup that the thread is currently in must be in the
856 same resource domain as the destination cgroup.
858 - It must have write access to the "cgroup.procs" file of the
864 cgroup.controllers
869 the cgroup. The controllers are not ordered.
871 cgroup.subtree_control
877 cgroup to its children.
886 cgroup.events
893 1 if the cgroup or its descendants contains any live
896 1 if the cgroup is frozen; otherwise, 0.
898 cgroup.max.descendants
903 an attempt to create a new cgroup in the hierarchy will fail.
905 cgroup.max.depth
908 Maximum allowed descent depth below the current cgroup.
910 an attempt to create a new child cgroup will fail.
912 cgroup.stat
919 Total number of dying descendant cgroups. A cgroup becomes
920 dying after being deleted by a user. The cgroup will remain
924 A process can't enter a dying cgroup under any circumstances,
925 a dying cgroup can't revive.
927 A dying cgroup can consume system resources not exceeding
928 limits, which were active at the moment of cgroup deletion.
930 cgroup.freeze
934 Writing "1" to the file causes freezing of the cgroup and all
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
942 A cgroup can be frozen either by its own settings, or by settings
944 cgroup will remain frozen.
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.
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
956 cgroup.kill
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
964 Killing a cgroup tree will deal with concurrent forks appropriately and
967 In a threaded cgroup, writing this file fails with EOPNOTSUPP as
993 the root cgroup. Be aware that system management software may already
995 process, and these processes may need to be moved to the root cgroup
1094 cgroup are tracked so that the total memory consumption can be
1118 The total amount of memory currently being used by the cgroup
1125 Hard memory protection. If the memory usage of a cgroup
1126 is within its effective min boundary, the cgroup's memory
1136 (child cgroup or cgroups are requiring more protected memory
1137 than parent will allow), then each child cgroup will get
1144 If a memory cgroup is not populated with processes,
1152 cgroup is within its effective low boundary, the cgroup's
1162 (child cgroup or cgroups are requiring more protected memory
1163 than parent will allow), then each child cgroup will get
1175 control memory usage of a cgroup. If a cgroup's usage goes
1176 over the high boundary, the processes of the cgroup are
1187 mechanism. If a cgroup's memory usage reaches this limit and
1188 can't be reduced, the OOM killer is invoked in the cgroup.
1207 Determines whether the cgroup should be treated as
1209 all tasks belonging to the cgroup or to its descendants
1210 (if the memory cgroup is not a leaf cgroup) are killed
1217 If the OOM killer is invoked in a cgroup, it's not going
1218 to kill any tasks outside of this cgroup, regardless
1229 hierarchy. For the local events at the cgroup level see
1233 The number of times the cgroup is reclaimed due to
1239 The number of times processes of the cgroup are
1242 cgroup whose memory usage is capped by the high limit
1247 The number of times the cgroup's memory usage was
1249 fails to bring it down, the cgroup goes to OOM state.
1252 The number of time the cgroup's memory usage was
1260 The number of processes belonging to this cgroup
1265 to the cgroup i.e. not hierarchical. The file modified event
1271 This breaks down the cgroup's memory footprint into different
1423 This breaks down the cgroup's memory footprint into different
1449 The total amount of swap currently being used by the cgroup
1456 Swap usage throttle limit. If a cgroup's swap usage exceeds
1460 This limit marks a point of no return for the cgroup. It is NOT
1463 prohibits swapping past a set amount, but lets the cgroup
1472 Swap usage hard limit. If a cgroup's swap usage reaches this
1473 limit, anonymous memory of the cgroup will not be swapped out.
1482 The number of times the cgroup's swap usage was over
1486 The number of times the cgroup's swap usage was about
1516 throttles the offending cgroup, a management agent has ample
1520 Determining whether a cgroup has enough memory is not trivial as
1534 A memory area is charged to the cgroup which instantiated it and stays
1535 charged to the cgroup until the area is released. Migrating a process
1536 to a different cgroup doesn't move the memory usages that it
1537 instantiated while in the previous cgroup to the new cgroup.
1540 To which cgroup the area will be charged is in-deterministic; however,
1541 over time, the memory area is likely to end up in a cgroup which has
1544 If a cgroup sweeps a considerable amount of memory which is expected
1585 cgroup.
1640 cgroup.
1677 If needed, tools/cgroup/iocost_coef_gen.py can be used to
1688 the cgroup can use in relation to its siblings.
1760 per-cgroup dirty memory states are examined and the more restrictive
1763 cgroup writeback requires explicit support from the underlying
1764 filesystem. Currently, cgroup writeback is implemented on ext2, ext4,
1766 attributed to the root cgroup.
1769 which affects how cgroup ownership is tracked. Memory is tracked per
1771 inode is assigned to a cgroup and all IO requests to write dirty pages
1772 from the inode are attributed to that cgroup.
1774 As cgroup ownership for memory is tracked per page, there can be pages
1778 cgroup becomes the majority over a certain period of time, switches
1779 the ownership of the inode to that cgroup.
1782 mostly dirtied by a single cgroup even when the main writing cgroup
1792 The sysctl knobs which affect writeback behavior are applied to cgroup
1796 These ratios apply the same to cgroup writeback with the
1801 For cgroup writeback, this is calculated into ratio against
1809 This is a cgroup v2 controller for IO workload protection. You provide a group
1888 A single attribute controls the behavior of the I/O priority cgroup policy,
1942 The process number controller is used to allow a cgroup to stop any
1946 The number of tasks in a cgroup can be exhausted in ways which other
1967 The number of processes currently in the cgroup and its
1970 Organisational operations are not blocked by cgroup policies, so it is
1973 processes to the cgroup such that pids.current is larger than
1974 pids.max. However, it is not possible to violate a cgroup PID policy
1976 of a new process would cause a cgroup policy to be violated.
1984 specified in the cpuset interface files in a task's current cgroup.
2002 cgroup. The actual list of CPUs to be granted, however, is
2012 An empty value indicates that the cgroup is using the same
2013 setting as the nearest cgroup ancestor with a non-empty
2024 cgroup by its parent. These CPUs are allowed to be used by
2025 tasks within the current cgroup.
2028 all the CPUs from the parent cgroup that can be available to
2029 be used by this cgroup. Otherwise, it should be a subset of
2041 this cgroup. The actual list of memory nodes granted, however,
2051 An empty value indicates that the cgroup is using the same
2052 setting as the nearest cgroup ancestor with a non-empty
2060 tasks within the cgroup to be migrated to the designated nodes if
2075 this cgroup by its parent. These memory nodes are allowed to
2076 be used by tasks within the current cgroup.
2079 parent cgroup that will be available to be used by this cgroup.
2088 cpuset-enabled cgroups. This flag is owned by the parent cgroup
2098 When set to be a partition root, the current cgroup is the
2102 cgroup is always a partition root.
2105 It can only be set in a cgroup if all the following conditions
2110 2) The parent cgroup is a partition root.
2118 effective CPUs of the parent cgroup. Once it is set, this
2145 granted by the parent cgroup.
2148 in "cpuset.cpus" can be granted by the parent cgroup or the
2149 parent cgroup is no longer a partition root itself. In this
2152 The cpu affinity of all the tasks in the cgroup will then be
2172 on top of cgroup BPF. To control access to device files, a user may
2220 It exists for all the cgroup except root.
2238 the cgroup except root.
2242 The default value is "max". It exists for all the cgroup except root.
2252 are local to the cgroup i.e. not hierarchical. The file modified event
2258 The Miscellaneous cgroup provides the resource limiting and tracking
2260 cgroup resources. Controller is enabled by the CONFIG_CGROUP_MISC config
2265 in the kernel/cgroup/misc.c file. Provider of the resource must set its
2278 A read-only flat-keyed file shown only in the root cgroup. It shows
2288 the current usage of the resources in the cgroup and its children.::
2296 maximum usage of the resources in the cgroup and its children.::
2316 A miscellaneous scalar resource is charged to the cgroup in which it is used
2317 first, and stays charged to that cgroup until that resource is freed. Migrating
2318 a process to a different cgroup does not move the charge to the destination
2319 cgroup where the process has moved.
2329 always be filtered by cgroup v2 path. The controller can still be
2340 CPU controller root cgroup process behaviour
2343 When distributing CPU cycles in the root cgroup each thread in this
2344 cgroup is treated as if it was hosted in a separate child cgroup of the
2345 root cgroup. This child cgroup weight is dependent on its thread nice
2353 IO controller root cgroup process behaviour
2356 Root cgroup processes are hosted in an implicit leaf child node.
2358 account as if it was a normal child cgroup of the root cgroup with a
2368 cgroup namespace provides a mechanism to virtualize the view of the
2369 "/proc/$PID/cgroup" file and cgroup mounts. The CLONE_NEWCGROUP clone
2370 flag can be used with clone(2) and unshare(2) to create a new cgroup
2371 namespace. The process running inside the cgroup namespace will have
2372 its "/proc/$PID/cgroup" output restricted to cgroupns root. The
2373 cgroupns root is the cgroup of the process at the time of creation of
2374 the cgroup namespace.
2376 Without cgroup namespace, the "/proc/$PID/cgroup" file shows the
2377 complete path of the cgroup of a process. In a container setup where
2379 "/proc/$PID/cgroup" file may leak potential system level information
2382 # cat /proc/self/cgroup
2386 and undesirable to expose to the isolated processes. cgroup namespace
2388 creating a cgroup namespace, one would see::
2390 # ls -l /proc/self/ns/cgroup
2391 lrwxrwxrwx 1 root root 0 2014-07-15 10:37 /proc/self/ns/cgroup -> cgroup:[4026531835]
2392 # cat /proc/self/cgroup
2397 # ls -l /proc/self/ns/cgroup
2398 lrwxrwxrwx 1 root root 0 2014-07-15 10:35 /proc/self/ns/cgroup -> cgroup:[4026532183]
2399 # cat /proc/self/cgroup
2402 When some thread from a multi-threaded process unshares its cgroup
2407 A cgroup namespace is alive as long as there are processes inside or
2408 mounts pinning it. When the last usage goes away, the cgroup
2416 The 'cgroupns root' for a cgroup namespace is the cgroup in which the
2418 /batchjobs/container_id1 cgroup calls unshare, cgroup
2420 init_cgroup_ns, this is the real root ('/') cgroup.
2422 The cgroupns root cgroup does not change even if the namespace creator
2423 process later moves to a different cgroup::
2425 # ~/unshare -c # unshare cgroupns in some cgroup
2426 # cat /proc/self/cgroup
2429 # echo 0 > sub_cgrp_1/cgroup.procs
2430 # cat /proc/self/cgroup
2433 Each process gets its namespace-specific view of "/proc/$PID/cgroup"
2435 Processes running inside the cgroup namespace will be able to see
2436 cgroup paths (in /proc/self/cgroup) only inside their root cgroup.
2441 # echo 7353 > sub_cgrp_1/cgroup.procs
2442 # cat /proc/7353/cgroup
2445 From the initial cgroup namespace, the real cgroup path will be
2448 $ cat /proc/7353/cgroup
2451 From a sibling cgroup namespace (that is, a namespace rooted at a
2452 different cgroup), the cgroup path relative to its own cgroup
2453 namespace root will be shown. For instance, if PID 7353's cgroup
2456 # cat /proc/7353/cgroup
2460 its relative to the cgroup namespace root of the caller.
2466 Processes inside a cgroup namespace can move into and out of the
2472 # cat /proc/7353/cgroup
2474 # echo 7353 > batchjobs/container_id2/cgroup.procs
2475 # cat /proc/7353/cgroup
2478 Note that this kind of setup is not encouraged. A task inside cgroup
2481 setns(2) to another cgroup namespace is allowed when:
2484 (b) the process has CAP_SYS_ADMIN against the target cgroup
2487 No implicit cgroup changes happen with attaching to another cgroup
2489 process under the target cgroup namespace root.
2495 Namespace specific cgroup hierarchy can be mounted by a process
2496 running inside a non-init cgroup namespace::
2500 This will mount the unified cgroup hierarchy with cgroupns root as the
2504 The virtualization of /proc/self/cgroup file combined with restricting
2505 the view of cgroup hierarchy by namespace-private cgroupfs mount
2506 provides a properly isolated cgroup view inside the container.
2513 where interacting with cgroup is necessary. cgroup core and
2520 A filesystem can support cgroup writeback by updating
2526 associates the bio with the inode's owner cgroup and the
2537 With writeback bio's annotated, cgroup support can be enabled per
2539 selective disabling of cgroup writeback support which is helpful when
2543 wbc_init_bio() binds the specified bio to its cgroup. Depending on
2559 - The "tasks" file is removed and "cgroup.procs" is not sorted.
2561 - "cgroup.clone_children" is removed.
2563 - /proc/cgroups is meaningless for v2. Use "cgroup.controllers" file
2573 cgroup v1 allowed an arbitrary number of hierarchies and each
2595 It greatly complicated cgroup core implementation but more importantly
2596 the support for multiple hierarchies restricted how cgroup could be
2600 that a thread's cgroup membership couldn't be described in finite
2626 cgroup v1 allowed threads of a process to belong to different cgroups.
2637 cgroup v1 had an ambiguously defined delegation model which got abused
2641 effectively raised cgroup to the status of a syscall-like API exposed
2644 First of all, cgroup has a fundamentally inadequate interface to be
2646 extract the path on the target hierarchy from /proc/self/cgroup,
2653 cgroup controllers implemented a number of knobs which would never be
2655 system-management pseudo filesystem. cgroup ended up with interface
2659 effectively abusing cgroup as a shortcut to implementing public APIs
2670 cgroup v1 allowed threads to be in any cgroups which created an
2671 interesting problem where threads belonging to a parent cgroup and its
2677 mapped nice levels to cgroup weights. This worked for some cases but
2686 cgroup to host the threads. The hidden leaf had its own copies of all
2702 made cgroup as a whole highly inconsistent.
2704 This clearly is a problem which needs to be addressed from cgroup core
2711 cgroup v1 grew without oversight and developed a large number of
2712 idiosyncrasies and inconsistencies. One issue on the cgroup core side
2713 was how an empty cgroup was notified - a userland helper binary was
2722 cgroup. Some controllers exposed a large amount of inconsistent
2725 There also was no consistency across controllers. When a new cgroup
2733 cgroup v2 establishes common conventions where appropriate and updates
2758 reserve. A cgroup enjoys reclaim protection when it's within its
2801 cgroup design was that global or parental pressure would always be
2810 that cgroup controllers should account and limit specific physical