Lines Matching full:controllers
30 2-4. Controlling Controllers
50 5. Controllers
108 qualifier as in "cgroup controllers". When explicitly referring to
119 cgroup is largely composed of two parts - the core and controllers.
123 although there are utility controllers which serve purposes other than
133 Following certain structural constraints, controllers may be enabled or
155 controllers which support v2 and are not bound to a v1 hierarchy are
157 Controllers which are not in active use in the v2 hierarchy can be
163 controller states are destroyed asynchronously and controllers may
169 to inter-controller dependencies, other controllers may need to be
173 controllers dynamically between the v2 and other hierarchies is
176 controllers after system boot.
179 automount the v1 cgroup filesystem and so hijack all controllers
182 disabling controllers in v1 and make them always available in v2.
198 controllers, and then seeding it with CLONE_INTO_CGROUP is
314 cgroup v2 supports thread granularity for a subset of controllers to
322 Controllers which support thread mode are called threaded controllers.
323 The ones which don't are called domain controllers.
334 constraint - threaded controllers can be enabled on non-leaf cgroups
362 controllers enabled or populated domain children. The root is
377 cgroup becomes threaded or threaded controllers are enabled in the
398 Only threaded controllers can be enabled in a threaded subtree. When
409 Currently, the following controllers are threaded and can be enabled
440 Controlling Controllers
448 "cgroup.controllers" file. Availability means the controller's interface files
455 Each cgroup has a "cgroup.controllers" file which lists all
456 controllers available for the cgroup to enable::
458 # cat cgroup.controllers
461 No controller is enabled by default. Controllers can be enabled and
466 Only controllers which are listed in "cgroup.controllers" can be
473 Consider the following sub-hierarchy. The enabled controllers are
500 can only contain controllers which are enabled in the parent's
512 controllers enabled in their "cgroup.subtree_control" files.
522 controllers. How resource consumption in the root cgroup is governed
524 refer to the Non-normative information section in the Controllers
532 children before enabling controllers in its "cgroup.subtree_control"
562 of all resource controllers are hierarchical and regardless of what
655 cgroup controllers implement several resource distribution schemes
777 reading; however, controllers may allow omitting later fields or
875 It can't be populated or have controllers enabled. It may
935 cgroup.controllers
939 It shows space separated list of all controllers available to
940 the cgroup. The controllers are not ordered.
946 When read, it shows space separated list of the controllers
950 Space separated list of controllers prefixed with '+' or '-'
951 can be written to enable or disable controllers. A controller
1091 Controllers chapter
1099 The "cpu" controllers regulates distribution of CPU cycles. This
1123 CONFIG_RT_GROUP_SCHED. Other controllers can be used for the resource control of
2270 This takes a similar format as the other controllers.
2362 controllers cannot prevent, thus warranting its own controller. For
3109 controllers are not covered.
3158 - /proc/cgroups is meaningless for v2. Use "cgroup.controllers" or
3169 hierarchy could host any number of controllers. While this seemed to
3173 type controllers such as freezer which can be useful in all
3175 the fact that controllers couldn't be moved to another hierarchy once
3176 hierarchies were populated. Another issue was that all controllers
3181 In practice, these issues heavily limited which controllers could be
3184 as the cpu and cpuacct controllers, made sense to be put on the same
3192 used in general and what controllers was able to do.
3198 addition of controllers which existed only to identify membership,
3203 topologies of hierarchies other controllers might be on, each
3204 controller had to assume that all other controllers were attached to
3206 least very cumbersome, for controllers to cooperate with each other.
3208 In most use cases, putting controllers on hierarchies which are
3213 controllers. For example, a given configuration might not care about
3222 This didn't make sense for some controllers and those controllers
3248 cgroup controllers implemented a number of knobs which would never be
3269 settle it. Different controllers did different things.
3294 Multiple controllers struggled with internal tasks and came up with
3315 controllers completely ignoring hierarchical organization and treating
3317 cgroup. Some controllers exposed a large amount of inconsistent
3320 There also was no consistency across controllers. When a new cgroup
3321 was created, some controllers defaulted to not imposing extra
3329 controllers so that they expose minimal and consistent interfaces.
3405 that cgroup controllers should account and limit specific physical