Lines Matching refs:that

49 A *subsystem* is a module that makes use of the task grouping
51 particular ways. A subsystem is typically a "resource controller" that
53 anything that wants to act on a group of processes, e.g. a
56 A *hierarchy* is a set of cgroups arranged in a tree, such that
69 associated with that instance of the cgroup file system.
72 tracking. The intention is that other subsystems hook into the generic
99 complex combinations of tasks that would be present if several
108 that can benefit from multiple hierarchies, consider a large
120                that they can run anywhere) with a limit of 20%
148 Also let's say that the administrator would like to give enhanced network
180    subsystem state is something that's expected to happen frequently
181    and in performance-critical code, whereas operations that require a
219 child cgroups created below the top-level cgroup, that hierarchy
231 containing the following files describing that cgroup:
233  - tasks: list of tasks (by PID) attached to that cgroup.  This list
239    Writing a thread group ID into this file moves all threads in that
250 modified by writing to the appropriate file in that cgroups
257 children of that task, to a cgroup allows organizing the work load
264 desired collection of cgroups then that group is reused, otherwise a new
269 that comprise it, a set of cg_cgroup_link objects form a lattice;
275 each css_set that references the cgroup, and sub-iterating over
287 some other cgroup) and the last child cgroup of that cgroup
289 of the "release_agent" file in that hierarchy's root directory,
308 To start a new job that is to be contained within a cgroup, using
316  5) Start a task that will be the "founding father" of the new job.
317  6) Attach that task to the new cgroup by writing its PID to the
318     /sys/fs/cgroup/cpuset tasks file for that cgroup.
323 and then start a subshell 'sh' in that cgroup:
352 /proc/mounts so may be any useful identifying string that you like.
356 for each new cgroup created before that group can be used.
382 Note that specifying 'release_agent' more than once will return failure.
384 Note that changing the set of subsystems is currently only supported
389 Then under /sys/fs/cgroup/rg1 you can find a tree that corresponds to the
391 is the cgroup that holds the whole system.
429 Note that it is PID, not PIDs. You can only attach ONE task at a time.
443 threadgroup to cgroup.procs causes all tasks in that threadgroup to be
481 Each kernel subsystem that wants to hook into the generic cgroup
505 system. This should be taken by anything that wants to modify a
507 modified, but more specific locks may be more appropriate in that
534 methods are css_alloc/free. Any others that are null are presumed to
546 cgroup system. Note that this will be called at initialization to
590   - it's guaranteed that all are from the same thread group
597 cgroup_taskset_for_each() iterator. Note that this isn't called on a
599 while the caller holds cgroup_mutex and it is ensured that either
611 that the hidden subsystem can return to the initial neutral state.
613 ensures that the configuration is in the initial state when it is made
621 function, so that the subsystem can implement a rollback. If not, not necessary.
629 post-attachment activity that requires memory allocations or blocking.
646 that is being created/destroyed (and hence has no sub-cgroups).