Lines Matching refs:in
50 facilities provided by cgroups to treat groups of tasks in
56 A *hierarchy* is a set of cgroups arranged in a tree, such that
57 every task in the system is in exactly one of the cgroups in the
59 state attached to each cgroup in the hierarchy. Each hierarchy has
63 cgroups. Each hierarchy is a partition of all tasks in the system.
65 User-level code may create and destroy cgroups by name in an
74 accounting/limiting the resources which processes in a cgroup can
77 tasks in each cgroup.
82 There are multiple efforts to provide process aggregations in the
87 up in the same group (cgroup) as their parent process.
103 At one extreme, each resource controller or subsystem could be in a
107 As an example of a scenario (originally proposed by vatsa@in.ibm.com)
137 (by putting those resource subsystems in different hierarchies),
171 - Each task in the system has a reference-counted pointer to a
176 registered in the system. There is no direct link from a task to
177 the cgroup of which it's a member in each hierarchy, but this
181 and in performance-critical code, whereas operations that require a
182 task's actual cgroup assignments (in particular, moving between
193 into the rest of the kernel, none in performance-critical paths:
195 - in init/main.c, to initialize the root cgroups and initial
198 - in fork and exit, to attach and detach a task from its css_set.
209 matches, and any of the requested subsystems are in use in an existing
215 hierarchy. This may be possible in future, but is fraught with nasty
230 Each cgroup is represented by a directory in the cgroup file system
236 - cgroup.procs: list of thread group IDs in the cgroup. This list is
239 Writing a thread group ID into this file moves all threads in that
243 exists in the top cgroup only)
245 Other subsystems such as cpusets may add additional files in each
250 modified by writing to the appropriate file in that cgroups
274 Thus the set of tasks in a cgroup can be listed by iterating over
285 If the notify_on_release flag is enabled (1) in a cgroup, then
286 whenever the last task in the cgroup leaves (exits or attaches to
289 of the "release_agent" file in that hierarchy's root directory,
293 notify_on_release in the root cgroup at system boot is disabled
302 flag is enabled (1) in a cgroup, a new cpuset cgroup will copy its
314 4) Create the new cgroup by doing mkdir's and write's (or echo's) in
323 and then start a subshell 'sh' in that cgroup:
335 # The subshell 'sh' is now running in cgroup Charlie
351 The "xxx" is not interpreted by the cgroup code, but will appear in
358 As explained in section `1.2 Why are cgroups needed?' you should create
375 conventional fsnotify. The support for remounting will be removed in
387 cgroup hierarchy is intended to be implemented in the future.
390 tree of the cgroups in the system. For instance, /sys/fs/cgroup/rg1
413 You can also create cgroups inside your cgroup by using mkdir in this
420 This will fail if the cgroup is in use (has cgroups inside, or
442 threads in a threadgroup at once. Echoing the PID of any task in a
443 threadgroup to cgroup.procs causes all tasks in that threadgroup to be
445 in the writing task's threadgroup.
447 Note: Since every task is always a member of exactly one cgroup in each
460 mounting a pre-existing hierarchy, in order to refer to it by name
472 in /proc/mounts and /proc/<pid>/cgroups.
486 Other fields in the cgroup_subsys object include:
489 entry in cgroup->subsys[] this subsystem should be managing.
507 modified, but more specific locks may be more appropriate in that
515 Accessing a task's cgroup pointer may be done in the following ways:
525 - add an entry in linux/cgroup_subsys.h
528 If a subsystem can be compiled as a module, it should also have in its
529 module initcall a call to cgroup_load_subsys(), and in its exitcall a
531 THIS_MODULE in its .c file.
544 a structure of type cgroup_subsys_state (typically embedded in a
587 least one task in it.
589 If there are multiple tasks in the taskset, then:
600 attach() or cancel_attach() will be called in future.
613 ensures that the configuration is in the initial state when it is made
651 cgroup filesystem supports certain types of extended attributes in its
658 Like in tmpfs, the extended attributes in cgroup filesystem are stored
661 any user can do it and there's no limit in the value size.
664 in containers and systemd for assorted meta data like main PID in a cgroup
672 errors. If you use it in the cgroup file system, you won't be