Lines Matching refs:hierarchy

100 distribute system resources along the hierarchy in a controlled and
106 distributing a specific type of system resource along the hierarchy
121 sub-hierarchy of the cgroup. When a controller is enabled on a nested
123 restrictions set closer to the root in the hierarchy can not be
133 Unlike v1, cgroup v2 has only single hierarchy. The cgroup v2
134 hierarchy can be mounted with the following mount command::
139 controllers which support v2 and are not bound to a v1 hierarchy are
140 automatically bound to the v2 hierarchy and show up at the root.
141 Controllers which are not in active use in the v2 hierarchy can be
142 bound to other hierarchies. This allows mixing v2 hierarchy with the
146 is no longer referenced in its current hierarchy. Because per-cgroup
149 the v2 hierarchy after the final umount of the previous hierarchy.
151 the unified hierarchy and it may take some time for the disabled
219 one for each hierarchy. The entry for cgroup v2 is always in the
250 cgroup whose resource domain is further up in the hierarchy. The root
337 "populated" field indicating whether the cgroup's sub-hierarchy has
342 sub-hierarchy have exited. The populated state updates and
343 notifications are recursive. Consider the following sub-hierarchy
380 Consider the following sub-hierarchy. The enabled controllers are
422 of the hierarchy which has it enabled, processes are always only on
464 delegated, the user can build sub-hierarchy under the directory,
468 happens in the delegated sub-hierarchy, nothing can escape the
472 cgroups in or nesting depth of a delegated sub-hierarchy; however,
479 A delegated sub-hierarchy is contained in the sense that processes
480 can't be moved into or out of the sub-hierarchy by the delegatee.
493 processes around freely in the delegated sub-hierarchy it can't pull
494 in from or push out to outside the sub-hierarchy.
502 ~ hierarchy ~
802 When delegating a sub-hierarchy, write access to this file
831 When delegating a sub-hierarchy, write access to this file
871 an attempt to create a new cgroup in the hierarchy will fail.
1480 The limits are only applied at the peer level in the hierarchy. This means that
1661 perf_event controller, if not mounted on a legacy hierarchy, is
1662 automatically enabled on the v2 hierarchy so that perf events can
1664 moved to a legacy hierarchy after v2 hierarchy is populated.
1738 the threads). This is natural for the v2 hierarchy; however, for the
1803 /batchjobs/container_id1, and assuming that the global hierarchy is
1813 namespace should only be exposed to its own cgroupns hierarchy.
1829 Namespace specific cgroup hierarchy can be mounted by a process
1834 This will mount the unified cgroup hierarchy with cgroupns root as the
1839 the view of cgroup hierarchy by namespace-private cgroupfs mount
1906 hierarchy could host any number of controllers. While this seemed to
1912 the fact that controllers couldn't be moved to another hierarchy once
1914 bound to a hierarchy were forced to have exactly the same view of the
1915 hierarchy. It wasn't possible to vary the granularity depending on
1919 put on the same hierarchy and most configurations resorted to putting
1920 each controller on its own hierarchy. Only closely related ones, such
1922 hierarchy. This often meant that userland ended up managing multiple
1923 similar hierarchies repeating the same steps on each hierarchy
1924 whenever a hierarchy management operation was necessary.
1948 depending on the specific controller. In other words, hierarchy may
1978 extract the path on the target hierarchy from /proc/self/cgroup,
1983 that the process would actually be operating on its own sub-hierarchy.
2083 in the hierarchy. This makes subtree delegation impossible. Second,
2142 and that's why unified hierarchy allows distributing it separately.