Lines Matching full:by

5 Written by Paul Menage <menage@google.com> based on
14 Modified by Paul Jackson <pj@sgi.com>
16 Modified by Christoph Lameter <cl@linux.com>
30 	2.3 Mounting hierarchies by name
54 facilities provided by cgroups to treat groups of tasks in
69 User-level code may create and destroy cgroups by name in an
111 As an example of a scenario (originally proposed by vatsa@in.ibm.com)
141 (by putting those resource subsystems in different hierarchies),
182    can be determined by following pointers through the
194  - You can list all the tasks (by PID) attached to any cgroup.
208 options.  By default, mounting the cgroup filesystem attempts to
234 Each cgroup is represented by a directory in the cgroup file system
237  - tasks: list of tasks (by PID) attached to that cgroup.  This list
254 modified by writing to the appropriate file in that cgroups
260 The attachment of each task, automatically inherited at fork by any
263 any other cgroup, if allowed by the permissions on the necessary
269 css_set is allocated. The appropriate existing css_set is located by
278 Thus the set of tasks in a cgroup can be listed by iterating over
292 is removed, then the kernel runs the command specified by the contents
318  4) Create the new cgroup by doing mkdir's and write's (or echo's) in
321  6) Attach that task to the new cgroup by writing its PID to the
356 The "xxx" is not interpreted by the cgroup code, but will appear in
419   (plus whatever files added by the attached subsystems)
425 You can also create cgroups inside your cgroup by using mkdir in this
435 has processes attached, or is held alive by other subsystem-specific
453 You can attach the current shell task by echoing 0::
465 move it into a new cgroup (possibly the root cgroup) by writing to the
468 Note: Due to some restrictions enforced by some cgroup subsystems, moving
471 2.3 Mounting hierarchies by name
476 mounting a pre-existing hierarchy, in order to refer to it by name
477 rather than by its set of active subsystems.  Each hierarchy is either
500 with a subsystem ID which will be assigned by the cgroup system.
513 Each cgroup object created by the system has an array of pointers,
514 indexed by subsystem ID; this pointer is entirely managed by the
520 There is a global mutex, cgroup_mutex, used by the cgroup
521 system. This should be taken by anything that wants to modify a
549 (cgroup_mutex held by caller)
556 larger subsystem-specific object), which will be initialized by the
559 identified by the passed cgroup object having a NULL parent (since
564 (cgroup_mutex held by caller)
568 subsystem may choose to fail creation by returning -errno. This
574 (cgroup_mutex held by caller)
584 (cgroup_mutex held by caller)
587 its subsystem state object. By the time this method is called, @cgrp
593 (cgroup_mutex held by caller)
614 (cgroup_mutex held by caller)
620 subsystems depend on it.  cgroup core makes such a css invisible by
628 (cgroup_mutex held by caller)
637 (cgroup_mutex held by caller)
656 (cgroup_mutex held by caller)