Lines Matching refs:be
7 their rationales. It will eventually be merged into the main cgroup
44 type controllers such as freezer which can be useful in all
45 hierarchies can only be used in one. The issue is exacerbated by the
46 fact that controllers can't be moved around once hierarchies are
51 In practice, these issues heavily limit which controllers can be put
64 There's no limit on how many hierarchies there may be, which means
65 that a task's cgroup membership can't be described in finite length.
72 of hierarchies other controllers would be on, each controller has to
81 be collapsed from leaf towards root when viewed from specific
97 Currently, unified hierarchy can be mounted with the following mount
106 root of unified hierarchy can be bound to other hierarchies. This
110 A controller can be moved across hierarchies only after the controller
115 hierarchy. Similarly, a controller should be fully disabled to be
119 may need to be disabled too.
143 distribution of the respective resources of the cgroup will be
159 controllers which can be enabled in the cgroup's
168 from the parent can be used in its children.
178 file. A controller can be enabled only if the parent has the
179 controller enabled and a controller can't be disabled if one or more
193 flat when children should be allocated specific ratios of CPU cycles
204 extra layer of nesting which may not be necessary, makes the interface
211 this direction will lead to problems which will be extremely difficult
219 It is clear that this is something which needs to be addressed from
236 consumption which can't be associated with any other cgroup and
242 important as otherwise it wouldn't be possible to create children of a
252 A cgroup can be delegated to a less privileged user by granting write
255 resources of the parent and thus must not be delegated along with the
267 this may in the future be limited explicitly.
289 C0's ancestors and may be completely different from C1. It's clear
297 only be able to move processes in each sub-hierarchy but also across
308 "cgroup.procs" and thus be denied with -EACCES.
316 subhierarchy becomes empty so that it can be cleaned up. cgroup
339 interface file which can be used to monitor whether the cgroup's
366 - The "cgroup.procs" file is not sorted. pids will be unique unless
380 In general, all controller files should be in one of the following
404 can be written at a time. For nested keyed files, the sub key pairs
405 may be specified in any order and not all pairs have to be specified.
410 - Settings for a single feature should generally be implemented in a
413 - In general, the root cgroup should be exempt from resource control
417 control knob should be named "weight" and have the range [1, 10000]
418 and 100 should be the default value. The values are chosen to allow
423 limit, the control knobs should be named "min" and "max"
425 gurantee and/or limit, the control knobs should be named "low" and
428 In the above four control files, the special token "max" should be
432 the default settings should be keyed with "default" and appear as
437 "events" should be created which lists event key value pairs.
438 Whenever a notifiable event happens, file modified event should be
448 and memory, and better suited given that it may be used for cgroup
461 file follows the following format. More fields may later be
497 settings may be omitted or specified in any order.
507 - A task can be moved into an empty cpuset, and again it takes on the
535 preferred reclaim pass. This allows the new low boundary to be
544 limit that can not budge, even if the OOM killer has to be called.
554 The memory.high boundary on the other hand can be set much more
565 can be exceeded. But even then it's mostly better to satisfy the
574 be manually counted by listening to memory.oom_control events, and
575 lower boundary / soft limit events have to be counted by first
579 information that a user needs to be reminded of every time they type
587 Very High Number, and a configured limit can be unset by echoing -1
590 be understood as an underflow into the highest possible value, -2 or
601 yet to be decided, for all resource control related knobs. Process
603 processes in sub-hierarchies may be delegated by changing the
622 useful features which may not be suitable for general consumption in a
628 kernel into a contract that can't be maintained in a reasonable
640 must be further abstracted and implemented as a different interface,
641 be it a system call or process-private filesystem, and survive through