Lines Matching full:controllers
30 2-4. Controlling Controllers
50 5. Controllers
109 qualifier as in "cgroup controllers". When explicitly referring to
120 cgroup is largely composed of two parts - the core and controllers.
124 although there are utility controllers which serve purposes other than
134 Following certain structural constraints, controllers may be enabled or
156 controllers which support v2 and are not bound to a v1 hierarchy are
158 Controllers which are not in active use in the v2 hierarchy can be
164 controller states are destroyed asynchronously and controllers may
170 to inter-controller dependencies, other controllers may need to be
174 controllers dynamically between the v2 and other hierarchies is
177 controllers after system boot.
180 automount the v1 cgroup filesystem and so hijack all controllers
183 disabling controllers in v1 and make them always available in v2.
199 controllers, and then seeding it with CLONE_INTO_CGROUP is
315 cgroup v2 supports thread granularity for a subset of controllers to
323 Controllers which support thread mode are called threaded controllers.
324 The ones which don't are called domain controllers.
335 constraint - threaded controllers can be enabled on non-leaf cgroups
363 controllers enabled or populated domain children. The root is
378 cgroup becomes threaded or threaded controllers are enabled in the
399 Only threaded controllers can be enabled in a threaded subtree. When
410 Currently, the following controllers are threaded and can be enabled
441 Controlling Controllers
449 "cgroup.controllers" file. Availability means the controller's interface files
456 Each cgroup has a "cgroup.controllers" file which lists all
457 controllers available for the cgroup to enable::
459 # cat cgroup.controllers
462 No controller is enabled by default. Controllers can be enabled and
467 Only controllers which are listed in "cgroup.controllers" can be
474 Consider the following sub-hierarchy. The enabled controllers are
501 can only contain controllers which are enabled in the parent's
513 controllers enabled in their "cgroup.subtree_control" files.
523 controllers. How resource consumption in the root cgroup is governed
525 refer to the Non-normative information section in the Controllers
533 children before enabling controllers in its "cgroup.subtree_control"
563 of all resource controllers are hierarchical and regardless of what
656 cgroup controllers implement several resource distribution schemes
775 reading; however, controllers may allow omitting later fields or
873 It can't be populated or have controllers enabled. It may
933 cgroup.controllers
937 It shows space separated list of all controllers available to
938 the cgroup. The controllers are not ordered.
944 When read, it shows space separated list of the controllers
948 Space separated list of controllers prefixed with '+' or '-'
949 can be written to enable or disable controllers. A controller
1089 Controllers chapter
1097 The "cpu" controllers regulates distribution of CPU cycles. This
1121 CONFIG_RT_GROUP_SCHED. Other controllers can be used for the resource control of
2290 This takes a similar format as the other controllers.
2382 controllers cannot prevent, thus warranting its own controller. For
3142 controllers are not covered.
3191 - /proc/cgroups is meaningless for v2. Use "cgroup.controllers" or
3202 hierarchy could host any number of controllers. While this seemed to
3206 type controllers such as freezer which can be useful in all
3208 the fact that controllers couldn't be moved to another hierarchy once
3209 hierarchies were populated. Another issue was that all controllers
3214 In practice, these issues heavily limited which controllers could be
3217 as the cpu and cpuacct controllers, made sense to be put on the same
3225 used in general and what controllers was able to do.
3231 addition of controllers which existed only to identify membership,
3236 topologies of hierarchies other controllers might be on, each
3237 controller had to assume that all other controllers were attached to
3239 least very cumbersome, for controllers to cooperate with each other.
3241 In most use cases, putting controllers on hierarchies which are
3246 controllers. For example, a given configuration might not care about
3255 This didn't make sense for some controllers and those controllers
3281 cgroup controllers implemented a number of knobs which would never be
3302 settle it. Different controllers did different things.
3327 Multiple controllers struggled with internal tasks and came up with
3348 controllers completely ignoring hierarchical organization and treating
3350 cgroup. Some controllers exposed a large amount of inconsistent
3353 There also was no consistency across controllers. When a new cgroup
3354 was created, some controllers defaulted to not imposing extra
3362 controllers so that they expose minimal and consistent interfaces.
3438 that cgroup controllers should account and limit specific physical