^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) ==============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) Control Groups
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) ==============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) Written by Paul Menage <menage@google.com> based on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6) Documentation/admin-guide/cgroup-v1/cpusets.rst
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) Original copyright statements from cpusets.txt:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) Portions Copyright (C) 2004 BULL SA.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) Portions Copyright (c) 2004-2006 Silicon Graphics, Inc.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) Modified by Paul Jackson <pj@sgi.com>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) Modified by Christoph Lameter <cl@linux.com>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) .. CONTENTS:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) 1. Control Groups
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) 1.1 What are cgroups ?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) 1.2 Why are cgroups needed ?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) 1.3 How are cgroups implemented ?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) 1.4 What does notify_on_release do ?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) 1.5 What does clone_children do ?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) 1.6 How do I use cgroups ?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) 2. Usage Examples and Syntax
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) 2.1 Basic Usage
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) 2.2 Attaching processes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) 2.3 Mounting hierarchies by name
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) 3. Kernel API
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) 3.1 Overview
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) 3.2 Synchronization
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) 3.3 Subsystem API
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) 4. Extended attributes usage
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) 5. Questions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) 1. Control Groups
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) =================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) 1.1 What are cgroups ?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) ----------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) Control Groups provide a mechanism for aggregating/partitioning sets of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) tasks, and all their future children, into hierarchical groups with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) specialized behaviour.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) Definitions:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) A *cgroup* associates a set of tasks with a set of parameters for one
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) or more subsystems.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) A *subsystem* is a module that makes use of the task grouping
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) facilities provided by cgroups to treat groups of tasks in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) particular ways. A subsystem is typically a "resource controller" that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) schedules a resource or applies per-cgroup limits, but it may be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) anything that wants to act on a group of processes, e.g. a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) virtualization subsystem.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) A *hierarchy* is a set of cgroups arranged in a tree, such that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) every task in the system is in exactly one of the cgroups in the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) hierarchy, and a set of subsystems; each subsystem has system-specific
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) state attached to each cgroup in the hierarchy. Each hierarchy has
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) an instance of the cgroup virtual filesystem associated with it.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) At any one time there may be multiple active hierarchies of task
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) cgroups. Each hierarchy is a partition of all tasks in the system.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) User-level code may create and destroy cgroups by name in an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) instance of the cgroup virtual file system, specify and query to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) which cgroup a task is assigned, and list the task PIDs assigned to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) a cgroup. Those creations and assignments only affect the hierarchy
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) associated with that instance of the cgroup file system.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) On their own, the only use for cgroups is for simple job
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) tracking. The intention is that other subsystems hook into the generic
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) cgroup support to provide new attributes for cgroups, such as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) accounting/limiting the resources which processes in a cgroup can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) access. For example, cpusets (see Documentation/admin-guide/cgroup-v1/cpusets.rst) allow
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) you to associate a set of CPUs and a set of memory nodes with the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) tasks in each cgroup.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) 1.2 Why are cgroups needed ?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) ----------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) There are multiple efforts to provide process aggregations in the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) Linux kernel, mainly for resource-tracking purposes. Such efforts
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) include cpusets, CKRM/ResGroups, UserBeanCounters, and virtual server
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) namespaces. These all require the basic notion of a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) grouping/partitioning of processes, with newly forked processes ending
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) up in the same group (cgroup) as their parent process.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) The kernel cgroup patch provides the minimum essential kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) mechanisms required to efficiently implement such groups. It has
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) minimal impact on the system fast paths, and provides hooks for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) specific subsystems such as cpusets to provide additional behaviour as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) desired.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) Multiple hierarchy support is provided to allow for situations where
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) the division of tasks into cgroups is distinctly different for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) different subsystems - having parallel hierarchies allows each
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) hierarchy to be a natural division of tasks, without having to handle
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) complex combinations of tasks that would be present if several
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) unrelated subsystems needed to be forced into the same tree of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) cgroups.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) At one extreme, each resource controller or subsystem could be in a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) separate hierarchy; at the other extreme, all subsystems
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) would be attached to the same hierarchy.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) As an example of a scenario (originally proposed by vatsa@in.ibm.com)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) that can benefit from multiple hierarchies, consider a large
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) university server with various users - students, professors, system
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) tasks etc. The resource planning for this server could be along the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) following lines::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) CPU : "Top cpuset"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) / \
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) CPUSet1 CPUSet2
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) | |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) (Professors) (Students)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) In addition (system tasks) are attached to topcpuset (so
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) that they can run anywhere) with a limit of 20%
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) Memory : Professors (50%), Students (30%), system (20%)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) Disk : Professors (50%), Students (30%), system (20%)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) Network : WWW browsing (20%), Network File System (60%), others (20%)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) / \
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) Professors (15%) students (5%)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) Browsers like Firefox/Lynx go into the WWW network class, while (k)nfsd goes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) into the NFS network class.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) At the same time Firefox/Lynx will share an appropriate CPU/Memory class
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) depending on who launched it (prof/student).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) With the ability to classify tasks differently for different resources
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) (by putting those resource subsystems in different hierarchies),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) the admin can easily set up a script which receives exec notifications
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) and depending on who is launching the browser he can::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) # echo browser_pid > /sys/fs/cgroup/<restype>/<userclass>/tasks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) With only a single hierarchy, he now would potentially have to create
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) a separate cgroup for every browser launched and associate it with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) appropriate network and other resource class. This may lead to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) proliferation of such cgroups.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) Also let's say that the administrator would like to give enhanced network
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) access temporarily to a student's browser (since it is night and the user
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) wants to do online gaming :)) OR give one of the student's simulation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) apps enhanced CPU power.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) With ability to write PIDs directly to resource classes, it's just a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) matter of::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) # echo pid > /sys/fs/cgroup/network/<new_class>/tasks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) (after some time)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) # echo pid > /sys/fs/cgroup/network/<orig_class>/tasks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) Without this ability, the administrator would have to split the cgroup into
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) multiple separate ones and then associate the new cgroups with the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) new resource classes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) 1.3 How are cgroups implemented ?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) ---------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) Control Groups extends the kernel as follows:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) - Each task in the system has a reference-counted pointer to a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) css_set.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) - A css_set contains a set of reference-counted pointers to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) cgroup_subsys_state objects, one for each cgroup subsystem
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) registered in the system. There is no direct link from a task to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) the cgroup of which it's a member in each hierarchy, but this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) can be determined by following pointers through the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) cgroup_subsys_state objects. This is because accessing the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) subsystem state is something that's expected to happen frequently
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) and in performance-critical code, whereas operations that require a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) task's actual cgroup assignments (in particular, moving between
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) cgroups) are less common. A linked list runs through the cg_list
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) field of each task_struct using the css_set, anchored at
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) css_set->tasks.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) - A cgroup hierarchy filesystem can be mounted for browsing and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) manipulation from user space.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) - You can list all the tasks (by PID) attached to any cgroup.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) The implementation of cgroups requires a few, simple hooks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) into the rest of the kernel, none in performance-critical paths:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) - in init/main.c, to initialize the root cgroups and initial
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) css_set at system boot.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) - in fork and exit, to attach and detach a task from its css_set.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) In addition, a new file system of type "cgroup" may be mounted, to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) enable browsing and modifying the cgroups presently known to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) kernel. When mounting a cgroup hierarchy, you may specify a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) comma-separated list of subsystems to mount as the filesystem mount
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) options. By default, mounting the cgroup filesystem attempts to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) mount a hierarchy containing all registered subsystems.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) If an active hierarchy with exactly the same set of subsystems already
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) exists, it will be reused for the new mount. If no existing hierarchy
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) matches, and any of the requested subsystems are in use in an existing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) hierarchy, the mount will fail with -EBUSY. Otherwise, a new hierarchy
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) is activated, associated with the requested subsystems.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) It's not currently possible to bind a new subsystem to an active
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) cgroup hierarchy, or to unbind a subsystem from an active cgroup
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) hierarchy. This may be possible in future, but is fraught with nasty
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) error-recovery issues.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) When a cgroup filesystem is unmounted, if there are any
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223) child cgroups created below the top-level cgroup, that hierarchy
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) will remain active even though unmounted; if there are no
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) child cgroups then the hierarchy will be deactivated.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) No new system calls are added for cgroups - all support for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) querying and modifying cgroups is via this cgroup file system.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) Each task under /proc has an added file named 'cgroup' displaying,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231) for each active hierarchy, the subsystem names and the cgroup name
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) as the path relative to the root of the cgroup file system.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) Each cgroup is represented by a directory in the cgroup file system
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235) containing the following files describing that cgroup:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) - tasks: list of tasks (by PID) attached to that cgroup. This list
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) is not guaranteed to be sorted. Writing a thread ID into this file
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239) moves the thread into this cgroup.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240) - cgroup.procs: list of thread group IDs in the cgroup. This list is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) not guaranteed to be sorted or free of duplicate TGIDs, and userspace
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242) should sort/uniquify the list if this property is required.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243) Writing a thread group ID into this file moves all threads in that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244) group into this cgroup.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245) - notify_on_release flag: run the release agent on exit?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246) - release_agent: the path to use for release notifications (this file
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247) exists in the top cgroup only)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249) Other subsystems such as cpusets may add additional files in each
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250) cgroup dir.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252) New cgroups are created using the mkdir system call or shell
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253) command. The properties of a cgroup, such as its flags, are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254) modified by writing to the appropriate file in that cgroups
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255) directory, as listed above.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257) The named hierarchical structure of nested cgroups allows partitioning
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258) a large system into nested, dynamically changeable, "soft-partitions".
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260) The attachment of each task, automatically inherited at fork by any
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261) children of that task, to a cgroup allows organizing the work load
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262) on a system into related sets of tasks. A task may be re-attached to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263) any other cgroup, if allowed by the permissions on the necessary
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264) cgroup file system directories.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 265)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 266) When a task is moved from one cgroup to another, it gets a new
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 267) css_set pointer - if there's an already existing css_set with the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 268) desired collection of cgroups then that group is reused, otherwise a new
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 269) css_set is allocated. The appropriate existing css_set is located by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 270) looking into a hash table.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 271)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 272) To allow access from a cgroup to the css_sets (and hence tasks)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 273) that comprise it, a set of cg_cgroup_link objects form a lattice;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 274) each cg_cgroup_link is linked into a list of cg_cgroup_links for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 275) a single cgroup on its cgrp_link_list field, and a list of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 276) cg_cgroup_links for a single css_set on its cg_link_list.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 277)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 278) Thus the set of tasks in a cgroup can be listed by iterating over
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 279) each css_set that references the cgroup, and sub-iterating over
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 280) each css_set's task set.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 281)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 282) The use of a Linux virtual file system (vfs) to represent the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 283) cgroup hierarchy provides for a familiar permission and name space
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 284) for cgroups, with a minimum of additional kernel code.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 285)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 286) 1.4 What does notify_on_release do ?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 287) ------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 288)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 289) If the notify_on_release flag is enabled (1) in a cgroup, then
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 290) whenever the last task in the cgroup leaves (exits or attaches to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 291) some other cgroup) and the last child cgroup of that cgroup
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 292) is removed, then the kernel runs the command specified by the contents
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 293) of the "release_agent" file in that hierarchy's root directory,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 294) supplying the pathname (relative to the mount point of the cgroup
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 295) file system) of the abandoned cgroup. This enables automatic
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 296) removal of abandoned cgroups. The default value of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 297) notify_on_release in the root cgroup at system boot is disabled
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 298) (0). The default value of other cgroups at creation is the current
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 299) value of their parents' notify_on_release settings. The default value of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 300) a cgroup hierarchy's release_agent path is empty.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 301)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 302) 1.5 What does clone_children do ?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 303) ---------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 304)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 305) This flag only affects the cpuset controller. If the clone_children
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 306) flag is enabled (1) in a cgroup, a new cpuset cgroup will copy its
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 307) configuration from the parent during initialization.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 308)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 309) 1.6 How do I use cgroups ?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 310) --------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 311)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 312) To start a new job that is to be contained within a cgroup, using
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 313) the "cpuset" cgroup subsystem, the steps are something like::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 314)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 315) 1) mount -t tmpfs cgroup_root /sys/fs/cgroup
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 316) 2) mkdir /sys/fs/cgroup/cpuset
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 317) 3) mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 318) 4) Create the new cgroup by doing mkdir's and write's (or echo's) in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 319) the /sys/fs/cgroup/cpuset virtual file system.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 320) 5) Start a task that will be the "founding father" of the new job.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 321) 6) Attach that task to the new cgroup by writing its PID to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 322) /sys/fs/cgroup/cpuset tasks file for that cgroup.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 323) 7) fork, exec or clone the job tasks from this founding father task.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 324)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 325) For example, the following sequence of commands will setup a cgroup
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 326) named "Charlie", containing just CPUs 2 and 3, and Memory Node 1,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 327) and then start a subshell 'sh' in that cgroup::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 328)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 329) mount -t tmpfs cgroup_root /sys/fs/cgroup
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 330) mkdir /sys/fs/cgroup/cpuset
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 331) mount -t cgroup cpuset -ocpuset /sys/fs/cgroup/cpuset
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 332) cd /sys/fs/cgroup/cpuset
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 333) mkdir Charlie
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 334) cd Charlie
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 335) /bin/echo 2-3 > cpuset.cpus
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 336) /bin/echo 1 > cpuset.mems
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 337) /bin/echo $$ > tasks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 338) sh
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 339) # The subshell 'sh' is now running in cgroup Charlie
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 340) # The next line should display '/Charlie'
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 341) cat /proc/self/cgroup
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 342)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 343) 2. Usage Examples and Syntax
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 344) ============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 345)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 346) 2.1 Basic Usage
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 347) ---------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 348)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 349) Creating, modifying, using cgroups can be done through the cgroup
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 350) virtual filesystem.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 351)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 352) To mount a cgroup hierarchy with all available subsystems, type::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 353)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 354) # mount -t cgroup xxx /sys/fs/cgroup
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 355)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 356) The "xxx" is not interpreted by the cgroup code, but will appear in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 357) /proc/mounts so may be any useful identifying string that you like.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 358)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 359) Note: Some subsystems do not work without some user input first. For instance,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 360) if cpusets are enabled the user will have to populate the cpus and mems files
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 361) for each new cgroup created before that group can be used.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 362)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 363) As explained in section `1.2 Why are cgroups needed?` you should create
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 364) different hierarchies of cgroups for each single resource or group of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 365) resources you want to control. Therefore, you should mount a tmpfs on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 366) /sys/fs/cgroup and create directories for each cgroup resource or resource
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 367) group::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 368)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 369) # mount -t tmpfs cgroup_root /sys/fs/cgroup
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 370) # mkdir /sys/fs/cgroup/rg1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 371)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 372) To mount a cgroup hierarchy with just the cpuset and memory
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 373) subsystems, type::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 374)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 375) # mount -t cgroup -o cpuset,memory hier1 /sys/fs/cgroup/rg1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 376)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 377) While remounting cgroups is currently supported, it is not recommend
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 378) to use it. Remounting allows changing bound subsystems and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 379) release_agent. Rebinding is hardly useful as it only works when the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 380) hierarchy is empty and release_agent itself should be replaced with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 381) conventional fsnotify. The support for remounting will be removed in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 382) the future.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 383)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 384) To Specify a hierarchy's release_agent::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 385)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 386) # mount -t cgroup -o cpuset,release_agent="/sbin/cpuset_release_agent" \
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 387) xxx /sys/fs/cgroup/rg1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 388)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 389) Note that specifying 'release_agent' more than once will return failure.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 390)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 391) Note that changing the set of subsystems is currently only supported
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 392) when the hierarchy consists of a single (root) cgroup. Supporting
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 393) the ability to arbitrarily bind/unbind subsystems from an existing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 394) cgroup hierarchy is intended to be implemented in the future.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 395)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 396) Then under /sys/fs/cgroup/rg1 you can find a tree that corresponds to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 397) tree of the cgroups in the system. For instance, /sys/fs/cgroup/rg1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 398) is the cgroup that holds the whole system.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 399)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 400) If you want to change the value of release_agent::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 401)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 402) # echo "/sbin/new_release_agent" > /sys/fs/cgroup/rg1/release_agent
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 403)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 404) It can also be changed via remount.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 405)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 406) If you want to create a new cgroup under /sys/fs/cgroup/rg1::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 407)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 408) # cd /sys/fs/cgroup/rg1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 409) # mkdir my_cgroup
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 410)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 411) Now you want to do something with this cgroup:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 412)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 413) # cd my_cgroup
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 414)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 415) In this directory you can find several files::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 416)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 417) # ls
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 418) cgroup.procs notify_on_release tasks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 419) (plus whatever files added by the attached subsystems)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 420)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 421) Now attach your shell to this cgroup::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 422)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 423) # /bin/echo $$ > tasks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 424)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 425) You can also create cgroups inside your cgroup by using mkdir in this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 426) directory::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 427)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 428) # mkdir my_sub_cs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 429)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 430) To remove a cgroup, just use rmdir::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 431)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 432) # rmdir my_sub_cs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 433)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 434) This will fail if the cgroup is in use (has cgroups inside, or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 435) has processes attached, or is held alive by other subsystem-specific
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 436) reference).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 437)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 438) 2.2 Attaching processes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 439) -----------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 440)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 441) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 442)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 443) # /bin/echo PID > tasks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 444)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 445) Note that it is PID, not PIDs. You can only attach ONE task at a time.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 446) If you have several tasks to attach, you have to do it one after another::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 447)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 448) # /bin/echo PID1 > tasks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 449) # /bin/echo PID2 > tasks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 450) ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 451) # /bin/echo PIDn > tasks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 452)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 453) You can attach the current shell task by echoing 0::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 454)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 455) # echo 0 > tasks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 456)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 457) You can use the cgroup.procs file instead of the tasks file to move all
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 458) threads in a threadgroup at once. Echoing the PID of any task in a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 459) threadgroup to cgroup.procs causes all tasks in that threadgroup to be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 460) attached to the cgroup. Writing 0 to cgroup.procs moves all tasks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 461) in the writing task's threadgroup.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 462)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 463) Note: Since every task is always a member of exactly one cgroup in each
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 464) mounted hierarchy, to remove a task from its current cgroup you must
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 465) move it into a new cgroup (possibly the root cgroup) by writing to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 466) new cgroup's tasks file.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 467)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 468) Note: Due to some restrictions enforced by some cgroup subsystems, moving
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 469) a process to another cgroup can fail.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 470)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 471) 2.3 Mounting hierarchies by name
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 472) --------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 473)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 474) Passing the name=<x> option when mounting a cgroups hierarchy
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 475) associates the given name with the hierarchy. This can be used when
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 476) mounting a pre-existing hierarchy, in order to refer to it by name
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 477) rather than by its set of active subsystems. Each hierarchy is either
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 478) nameless, or has a unique name.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 479)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 480) The name should match [\w.-]+
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 481)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 482) When passing a name=<x> option for a new hierarchy, you need to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 483) specify subsystems manually; the legacy behaviour of mounting all
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 484) subsystems when none are explicitly specified is not supported when
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 485) you give a subsystem a name.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 486)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 487) The name of the subsystem appears as part of the hierarchy description
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 488) in /proc/mounts and /proc/<pid>/cgroups.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 489)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 490)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 491) 3. Kernel API
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 492) =============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 493)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 494) 3.1 Overview
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 495) ------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 496)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 497) Each kernel subsystem that wants to hook into the generic cgroup
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 498) system needs to create a cgroup_subsys object. This contains
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 499) various methods, which are callbacks from the cgroup system, along
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 500) with a subsystem ID which will be assigned by the cgroup system.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 501)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 502) Other fields in the cgroup_subsys object include:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 503)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 504) - subsys_id: a unique array index for the subsystem, indicating which
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 505) entry in cgroup->subsys[] this subsystem should be managing.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 506)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 507) - name: should be initialized to a unique subsystem name. Should be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 508) no longer than MAX_CGROUP_TYPE_NAMELEN.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 509)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 510) - early_init: indicate if the subsystem needs early initialization
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 511) at system boot.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 512)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 513) Each cgroup object created by the system has an array of pointers,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 514) indexed by subsystem ID; this pointer is entirely managed by the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 515) subsystem; the generic cgroup code will never touch this pointer.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 516)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 517) 3.2 Synchronization
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 518) -------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 519)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 520) There is a global mutex, cgroup_mutex, used by the cgroup
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 521) system. This should be taken by anything that wants to modify a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 522) cgroup. It may also be taken to prevent cgroups from being
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 523) modified, but more specific locks may be more appropriate in that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 524) situation.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 525)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 526) See kernel/cgroup.c for more details.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 527)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 528) Subsystems can take/release the cgroup_mutex via the functions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 529) cgroup_lock()/cgroup_unlock().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 530)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 531) Accessing a task's cgroup pointer may be done in the following ways:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 532) - while holding cgroup_mutex
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 533) - while holding the task's alloc_lock (via task_lock())
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 534) - inside an rcu_read_lock() section via rcu_dereference()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 535)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 536) 3.3 Subsystem API
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 537) -----------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 538)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 539) Each subsystem should:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 540)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 541) - add an entry in linux/cgroup_subsys.h
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 542) - define a cgroup_subsys object called <name>_cgrp_subsys
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 543)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 544) Each subsystem may export the following methods. The only mandatory
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 545) methods are css_alloc/free. Any others that are null are presumed to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 546) be successful no-ops.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 547)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 548) ``struct cgroup_subsys_state *css_alloc(struct cgroup *cgrp)``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 549) (cgroup_mutex held by caller)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 550)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 551) Called to allocate a subsystem state object for a cgroup. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 552) subsystem should allocate its subsystem state object for the passed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 553) cgroup, returning a pointer to the new object on success or a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 554) ERR_PTR() value. On success, the subsystem pointer should point to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 555) a structure of type cgroup_subsys_state (typically embedded in a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 556) larger subsystem-specific object), which will be initialized by the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 557) cgroup system. Note that this will be called at initialization to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 558) create the root subsystem state for this subsystem; this case can be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 559) identified by the passed cgroup object having a NULL parent (since
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 560) it's the root of the hierarchy) and may be an appropriate place for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 561) initialization code.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 562)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 563) ``int css_online(struct cgroup *cgrp)``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 564) (cgroup_mutex held by caller)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 565)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 566) Called after @cgrp successfully completed all allocations and made
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 567) visible to cgroup_for_each_child/descendant_*() iterators. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 568) subsystem may choose to fail creation by returning -errno. This
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 569) callback can be used to implement reliable state sharing and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 570) propagation along the hierarchy. See the comment on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 571) cgroup_for_each_descendant_pre() for details.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 572)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 573) ``void css_offline(struct cgroup *cgrp);``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 574) (cgroup_mutex held by caller)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 575)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 576) This is the counterpart of css_online() and called iff css_online()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 577) has succeeded on @cgrp. This signifies the beginning of the end of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 578) @cgrp. @cgrp is being removed and the subsystem should start dropping
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 579) all references it's holding on @cgrp. When all references are dropped,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 580) cgroup removal will proceed to the next step - css_free(). After this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 581) callback, @cgrp should be considered dead to the subsystem.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 582)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 583) ``void css_free(struct cgroup *cgrp)``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 584) (cgroup_mutex held by caller)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 585)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 586) The cgroup system is about to free @cgrp; the subsystem should free
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 587) its subsystem state object. By the time this method is called, @cgrp
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 588) is completely unused; @cgrp->parent is still valid. (Note - can also
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 589) be called for a newly-created cgroup if an error occurs after this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 590) subsystem's create() method has been called for the new cgroup).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 591)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 592) ``int can_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 593) (cgroup_mutex held by caller)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 594)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 595) Called prior to moving one or more tasks into a cgroup; if the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 596) subsystem returns an error, this will abort the attach operation.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 597) @tset contains the tasks to be attached and is guaranteed to have at
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 598) least one task in it.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 599)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 600) If there are multiple tasks in the taskset, then:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 601) - it's guaranteed that all are from the same thread group
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 602) - @tset contains all tasks from the thread group whether or not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 603) they're switching cgroups
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 604) - the first task is the leader
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 605)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 606) Each @tset entry also contains the task's old cgroup and tasks which
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 607) aren't switching cgroup can be skipped easily using the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 608) cgroup_taskset_for_each() iterator. Note that this isn't called on a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 609) fork. If this method returns 0 (success) then this should remain valid
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 610) while the caller holds cgroup_mutex and it is ensured that either
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 611) attach() or cancel_attach() will be called in future.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 612)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 613) ``void css_reset(struct cgroup_subsys_state *css)``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 614) (cgroup_mutex held by caller)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 615)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 616) An optional operation which should restore @css's configuration to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 617) initial state. This is currently only used on the unified hierarchy
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 618) when a subsystem is disabled on a cgroup through
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 619) "cgroup.subtree_control" but should remain enabled because other
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 620) subsystems depend on it. cgroup core makes such a css invisible by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 621) removing the associated interface files and invokes this callback so
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 622) that the hidden subsystem can return to the initial neutral state.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 623) This prevents unexpected resource control from a hidden css and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 624) ensures that the configuration is in the initial state when it is made
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 625) visible again later.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 626)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 627) ``void cancel_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 628) (cgroup_mutex held by caller)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 629)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 630) Called when a task attach operation has failed after can_attach() has succeeded.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 631) A subsystem whose can_attach() has some side-effects should provide this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 632) function, so that the subsystem can implement a rollback. If not, not necessary.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 633) This will be called only about subsystems whose can_attach() operation have
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 634) succeeded. The parameters are identical to can_attach().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 635)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 636) ``void attach(struct cgroup *cgrp, struct cgroup_taskset *tset)``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 637) (cgroup_mutex held by caller)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 638)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 639) Called after the task has been attached to the cgroup, to allow any
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 640) post-attachment activity that requires memory allocations or blocking.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 641) The parameters are identical to can_attach().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 642)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 643) ``void fork(struct task_struct *task)``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 644)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 645) Called when a task is forked into a cgroup.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 646)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 647) ``void exit(struct task_struct *task)``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 648)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 649) Called during task exit.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 650)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 651) ``void free(struct task_struct *task)``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 652)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 653) Called when the task_struct is freed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 654)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 655) ``void bind(struct cgroup *root)``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 656) (cgroup_mutex held by caller)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 657)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 658) Called when a cgroup subsystem is rebound to a different hierarchy
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 659) and root cgroup. Currently this will only involve movement between
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 660) the default hierarchy (which never has sub-cgroups) and a hierarchy
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 661) that is being created/destroyed (and hence has no sub-cgroups).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 662)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 663) 4. Extended attribute usage
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 664) ===========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 665)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 666) cgroup filesystem supports certain types of extended attributes in its
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 667) directories and files. The current supported types are:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 668)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 669) - Trusted (XATTR_TRUSTED)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 670) - Security (XATTR_SECURITY)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 671)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 672) Both require CAP_SYS_ADMIN capability to set.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 673)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 674) Like in tmpfs, the extended attributes in cgroup filesystem are stored
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 675) using kernel memory and it's advised to keep the usage at minimum. This
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 676) is the reason why user defined extended attributes are not supported, since
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 677) any user can do it and there's no limit in the value size.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 678)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 679) The current known users for this feature are SELinux to limit cgroup usage
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 680) in containers and systemd for assorted meta data like main PID in a cgroup
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 681) (systemd creates a cgroup per service).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 682)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 683) 5. Questions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 684) ============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 685)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 686) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 687)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 688) Q: what's up with this '/bin/echo' ?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 689) A: bash's builtin 'echo' command does not check calls to write() against
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 690) errors. If you use it in the cgroup file system, you won't be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 691) able to tell whether a command succeeded or failed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 692)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 693) Q: When I attach processes, only the first of the line gets really attached !
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 694) A: We can only return one error code per call to write(). So you should also
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 695) put only ONE PID.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags