Lines Matching refs:hierarchy
56 A *hierarchy* is a set of cgroups arranged in a tree, such that
58 hierarchy, and a set of subsystems; each subsystem has system-specific
59 state attached to each cgroup in the hierarchy. Each hierarchy has
63 cgroups. Each hierarchy is a partition of all tasks in the system.
68 a cgroup. Those creations and assignments only affect the hierarchy
95 Multiple hierarchy support is provided to allow for situations where
98 hierarchy to be a natural division of tasks, without having to handle
104 separate hierarchy; at the other extreme, all subsystems
105 would be attached to the same hierarchy.
143 With only a single hierarchy, he now would potentially have to create
177 the cgroup of which it's a member in each hierarchy, but this
187 - A cgroup hierarchy filesystem can be mounted for browsing and
202 kernel. When mounting a cgroup hierarchy, you may specify a
205 mount a hierarchy containing all registered subsystems.
207 If an active hierarchy with exactly the same set of subsystems already
208 exists, it will be reused for the new mount. If no existing hierarchy
210 hierarchy, the mount will fail with -EBUSY. Otherwise, a new hierarchy
214 cgroup hierarchy, or to unbind a subsystem from an active cgroup
215 hierarchy. This may be possible in future, but is fraught with nasty
219 child cgroups created below the top-level cgroup, that hierarchy
221 child cgroups then the hierarchy will be deactivated.
227 for each active hierarchy, the subsystem names and the cgroup name
279 cgroup hierarchy provides for a familiar permission and name space
289 of the "release_agent" file in that hierarchy's root directory,
296 a cgroup hierarchy's release_agent path is empty.
348 To mount a cgroup hierarchy with all available subsystems, type:
367 To mount a cgroup hierarchy with just the cpuset and memory
374 hierarchy is empty and release_agent itself should be replaced with
378 To Specify a hierarchy's release_agent:
385 when the hierarchy consists of a single (root) cgroup. Supporting
387 cgroup hierarchy is intended to be implemented in the future.
448 mounted hierarchy, to remove a task from its current cgroup you must
458 Passing the name=<x> option when mounting a cgroups hierarchy
459 associates the given name with the hierarchy. This can be used when
460 mounting a pre-existing hierarchy, in order to refer to it by name
461 rather than by its set of active subsystems. Each hierarchy is either
466 When passing a name=<x> option for a new hierarchy, you need to
471 The name of the subsystem appears as part of the hierarchy description
549 it's the root of the hierarchy) and may be an appropriate place for
559 propagation along the hierarchy. See the comment on
606 initial state. This is currently only used on the unified hierarchy
647 Called when a cgroup subsystem is rebound to a different hierarchy
649 the default hierarchy (which never has sub-cgroups) and a hierarchy