Lines Matching refs:cgroup
7 their rationales. It will eventually be merged into the main cgroup
15 2-2. cgroup.subtree_control
16 2-3. cgroup.controllers
39 cgroup allows an arbitrary number of hierarchies and each hierarchy
60 Internal implementation in cgroup core proper is dazzlingly
62 restricts how cgroup is used in general and what controllers can do.
65 that a task's cgroup membership can't be described in finite length.
86 Unified hierarchy is the next version of cgroup interface. It aims to
101 mount -t cgroup -o __DEVEL__sane_behavior cgroup $MOUNT_POINT
111 is no longer referenced in its current hierarchy. Because per-cgroup
128 2-2. cgroup.subtree_control
130 All cgroups on unified hierarchy have a "cgroup.subtree_control" file
132 cgroup. Let's assume a hierarchy like the following.
137 root's "cgroup.subtree_control" file determines which controllers are
142 Enabling a controller in a "cgroup.subtree_control" file declares that
143 distribution of the respective resources of the cgroup will be
156 2-3. cgroup.controllers
158 Read-only "cgroup.controllers" file contains a space-separated list of
159 controllers which can be enabled in the cgroup's
160 "cgroup.subtree_control" file.
162 In the root cgroup, this lists controllers which are not bound to
167 parent's "cgroup.subtree_control" file as only controllers enabled
176 all non-root "cgroup.subtree_control" files can only contain
177 controllers which are enabled in the parent's "cgroup.subtree_control"
185 One long-standing issue that cgroup faces is the competition between
186 tasks belonging to the parent cgroup and its children cgroups. This
192 nice levels to cgroup weights. This works for some cases but falls
201 cgroup to host the tasks. The hidden leaf has its own copies of all
217 behaviors make cgroup as whole highly inconsistent.
220 cgroup core proper in a uniform way so that controllers don't need to
221 worry about it and cgroup as a whole shows a consistent and logical
226 have controllers enabled in their "cgroup.subtree_control" files.
234 There are two things to note. Firstly, the root cgroup is exempt from
236 consumption which can't be associated with any other cgroup and
238 consumption in the root cgroup is governed is up to each controller.
241 controller in the cgroup's "cgroup.subtree_control" file. This is
243 populated cgroup. To control resource distribution of a cgroup, the
244 cgroup must create children and transfer all its tasks to the children
245 before enabling controllers in its "cgroup.subtree_control" file.
252 A cgroup can be delegated to a less privileged user by granting write
253 access of the directory and its "cgroup.procs" file to the user. Note
265 Currently, cgroup doesn't impose any restrictions on the number of
272 On the unified hierarchy, to write to a "cgroup.procs" file, in
274 writer must also have write access to the "cgroup.procs" file of the
282 ~ cgroup ~ \ C01
295 "cgroup.procs" file of a cgroup and its uid agrees with the target, it
296 can move the target to the cgroup. In the above example, U0 will not
304 "C00/cgroup.procs". U0 obviously has write access to the file and
306 the source cgroup C10 and the destination cgroup C00 is above the
308 "cgroup.procs" and thus be denied with -EACCES.
315 cgroup users often need a way to determine when a cgroup's
316 subhierarchy becomes empty so that it can be cleaned up. cgroup
328 - The event isn't recursive. It triggers when a cgroup doesn't have
338 Unified hierarchy implements "populated" field in "cgroup.events"
339 interface file which can be used to monitor whether the cgroup's
341 task in the cgroup and its descendants; otherwise, 1. poll and
364 granularity. Use the "cgroup.procs" file instead.
366 - The "cgroup.procs" file is not sorted. pids will be unique unless
369 - The "cgroup.clone_children" file is removed.
371 - /proc/PID/cgroup keeps reporting the cgroup that a zombie belonged
372 to before exiting. If the cgroup is removed before the zombie is
413 - In general, the root cgroup should be exempt from resource control
448 and memory, and better suited given that it may be used for cgroup
513 - use_hierarchy is on by default and the cgroup file for the flag is
531 reserve. A cgroup enjoys reclaim protection when it and all its
604 ownership and/or permissions on the cgroup directory and
605 "cgroup.procs" interface file; however, all operations which affect
606 resource control - writes to a "cgroup.subtree_control" file or any
609 This, in part, is to prevent the cgroup interface from being
611 binaries. cgroup exposes various aspects of the system in ways which
616 access "my cgroup" in a race-free way or make multiple operations
617 atomic against migration to another cgroup.
619 Another aspect is that, for better or for worse, the cgroup interface
621 unprivileged userland. The upside is that cgroup is able to expose
631 Also, due to the specific nature, cgroup and its controllers don't
632 tend to attract attention from a wide scope of developers. cgroup's
637 Keeping cgroup as an administration interface is both advantageous for
638 its role and imperative given its nature. Some of the cgroup features
646 significant deterrent against spraying cgroup usages in non-privileged