Lines Matching refs:and
6 This document describes the changes made by unified hierarchy and
39 cgroup allows an arbitrary number of hierarchies and each hierarchy
52 on the same hierarchy and most configurations resort to putting each
54 the cpu and cpuacct controllers, make sense to put on the same
62 restricts how cgroup is used in general and what controllers can do.
66 The key may contain any varying number of entries and is unlimited in
67 length, which makes it highly awkward to handle and leads to addition
89 general and controller-specific interface issues are also addressed in
98 command. Note that this is still under development and scheduled to
103 All controllers which support the unified hierarchy and are not bound
104 to other hierarchies are automatically bound to unified hierarchy and
112 controller states are destroyed asynchronously and controllers may
116 moved out of the unified hierarchy and it may take some time for the
121 While useful for development and manual configurations, dynamically
122 moving controllers between the unified and other hierarchies is
124 the hierarchies and controller associations before starting using the
138 enabled on A. A's on B. B's on C and D. This coincides with the
150 the quotes). Controllers prefixed with '+' are enabled and '-'
163 other hierarchies and the content changes as controllers are bound to
164 and unbound from other hierarchies.
179 controller enabled and a controller can't be disabled if one or more
186 tasks belonging to the parent cgroup and its children cgroups. This
187 is inherently nasty as two different types of entities compete and
191 The cpu controller considers tasks and cgroups as equivalents and maps
194 and the number of internal tasks fluctuates - the ratios constantly
197 universal, and there are various other knobs which simply aren't
205 messy and significantly complicates the implementation.
208 happens between internal tasks and child cgroups and the behavior is
210 and knobs to tailor the behavior to specific workloads. Continuing
214 Multiple controllers struggle with internal tasks and came up with
216 use now are severely flawed and, furthermore, the widely different
221 worry about it and cgroup as a whole shows a consistent and logical
235 the restriction. Root contains tasks and anonymous resource
236 consumption which can't be associated with any other cgroup and
244 cgroup must create children and transfer all its tasks to the children
253 access of the directory and its "cgroup.procs" file to the user. Note
255 resources of the parent and thus must not be delegated along with the
259 organize processes as it sees fit and further distribute the resources
260 it got from the parent. The limits and other settings of all resource
261 controllers are hierarchical and regardless of what happens in the
273 addition to the usual write permission to the file and uid match, the
275 common ancestor of the source and destination cgroups. This prevents
278 Let's say cgroups C0 and C1 have been delegated to user U0 who created
279 C00, C01 under C0 and C10 under C1 as follows.
286 C0 and C1 are separate entities in terms of resource distribution
289 C0's ancestors and may be completely different from C1. It's clear
291 the processes under C0 and further control the distribution of C0's
295 "cgroup.procs" file of a cgroup and its uid agrees with the target, it
299 organizational and resource restrictions implied by the hierarchical
300 structure above C0 and C1.
303 process which has a matching uid and is currently in C10 into
304 "C00/cgroup.procs". U0 obviously has write access to the file and
306 the source cgroup C10 and the destination cgroup C00 is above the
307 points of delegation and U0 would not have write access to its
308 "cgroup.procs" and thus be denied with -EACCES.
320 - It delivers events by forking and execing a userland binary
322 notification delivery. It's extremely heavy, slow and cumbersome to
335 unnecessarily complicated and probably done this way because event
341 task in the cgroup and its descendants; otherwise, 1. poll and
344 This is significantly lighter and simpler and trivially allows
347 in the subhierarchy and monitor events that it's interested in from
351 supported and the interface files "release_agent" and
403 For both flat and nested keyed files, only the values for a single key
405 may be specified in any order and not all pairs have to be specified.
414 and thus shouldn't have resource control knobs.
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
419 enough and symmetric bias in both directions while keeping it
422 - If a controller implements an absolute resource guarantee and/or
423 limit, the control knobs should be named "min" and "max"
425 gurantee and/or limit, the control knobs should be named "low" and
429 used to represent upward infinity for both reading and writing.
431 - If a setting has configurable default value and specific overrides,
432 the default settings should be keyed with "default" and appear as
448 and memory, and better suited given that it may be used for cgroup
452 recursive stat files pointless and, as no internal node can have
454 simplified and the interface is overhauled accordingly.
468 The weight setting, currently only available and effective if
470 between 1 and 10000 and defaults to 100. The first line
489 The maximum bandwidth and/or iops setting, only available if
494 ${R|W}BPS are read/write bytes per second and ${R|W}IOPS are
504 - Tasks are kept in empty cpusets after hotplug and take on the masks
507 - A task can be moved into an empty cpuset, and again it takes on the
513 - use_hierarchy is on by default and the cgroup file for the flag is
523 global rbtree and treated like equal peers, regardless where they
531 reserve. A cgroup enjoys reclaim protection when it and all its
534 default and in the common case most cgroups are eligible for the
537 reclaim code, without the need for out-of-band data structures and
547 during runtime, and that requires users to overcommit. But doing
550 Since working set size estimation is hard and error prone, and
552 side of a looser limit and end up wasting precious resources.
560 and make corrections until the minimal memory footprint that still
563 In extreme cases, with many concurrent allocations and a complete
568 to limit this type of spillover and ultimately contain buggy or even
571 - The original control file names are unwieldy and inconsistent in
574 be manually counted by listening to memory.oom_control events, and
576 setting a threshold for that value and then counting those events.
577 Also, usage and limit files encode their units in the filename.
587 Very High Number, and a configured limit can be unset by echoing -1
588 into those files. But that very high number is implementation and
589 architecture dependent and not very descriptive. And while -1 can
593 memory.low, memory.high, and memory.max will use the string "max" to
594 indicate and set the highest possible value.
602 organization operations - creation of sub-cgroups and migration of
604 ownership and/or permissions on the cgroup directory and
624 internal details and userland-visible interface. Of course, this
631 Also, due to the specific nature, cgroup and its controllers don't
634 interfaces, unnecessary commitments to and exposing of internal
635 details, broken and dangerous implementations of various features.
638 its role and imperative given its nature. Some of the cgroup features
640 must be further abstracted and implemented as a different interface,
641 be it a system call or process-private filesystem, and survive through