Lines Matching refs:by

4 Written by Paul Menage <menage@google.com> based on
10 Modified by Paul Jackson <pj@sgi.com>
11 Modified by Christoph Lameter <clameter@sgi.com>
26   2.3 Mounting hierarchies by name
50 facilities provided by cgroups to treat groups of tasks in
65 User-level code may create and destroy cgroups by name in an
107 As an example of a scenario (originally proposed by vatsa@in.ibm.com)
137 (by putting those resource subsystems in different hierarchies),
178    can be determined by following pointers through the
190  - You can list all the tasks (by PID) attached to any cgroup.
230 Each cgroup is represented by a directory in the cgroup file system
233  - tasks: list of tasks (by PID) attached to that cgroup.  This list
250 modified by writing to the appropriate file in that cgroups
256 The attachment of each task, automatically inherited at fork by any
259 any other cgroup, if allowed by the permissions on the necessary
265 css_set is allocated. The appropriate existing css_set is located by
274 Thus the set of tasks in a cgroup can be listed by iterating over
288 is removed, then the kernel runs the command specified by the contents
314  4) Create the new cgroup by doing mkdir's and write's (or echo's) in
317  6) Attach that task to the new cgroup by writing its PID to the
351 The "xxx" is not interpreted by the cgroup code, but will appear in
408 (plus whatever files added by the attached subsystems)
413 You can also create cgroups inside your cgroup by using mkdir in this
421 has processes attached, or is held alive by other subsystem-specific
437 You can attach the current shell task by echoing 0:
449 move it into a new cgroup (possibly the root cgroup) by writing to the
452 Note: Due to some restrictions enforced by some cgroup subsystems, moving
455 2.3 Mounting hierarchies by name
460 mounting a pre-existing hierarchy, in order to refer to it by name
461 rather than by its set of active subsystems.  Each hierarchy is either
484 with a subsystem ID which will be assigned by the cgroup system.
497 Each cgroup object created by the system has an array of pointers,
498 indexed by subsystem ID; this pointer is entirely managed by the
504 There is a global mutex, cgroup_mutex, used by the cgroup
505 system. This should be taken by anything that wants to modify a
538 (cgroup_mutex held by caller)
545 larger subsystem-specific object), which will be initialized by the
548 identified by the passed cgroup object having a NULL parent (since
553 (cgroup_mutex held by caller)
557 subsystem may choose to fail creation by returning -errno. This
563 (cgroup_mutex held by caller)
573 (cgroup_mutex held by caller)
582 (cgroup_mutex held by caller)
603 (cgroup_mutex held by caller)
609 subsystems depend on it.  cgroup core makes such a css invisible by
617 (cgroup_mutex held by caller)
626 (cgroup_mutex held by caller)
645 (cgroup_mutex held by caller)