Lines Matching refs:a
40 Control Groups provide a mechanism for aggregating/partitioning sets of
46 A *cgroup* associates a set of tasks with a set of parameters for one
49 A *subsystem* is a module that makes use of the task grouping
51 particular ways. A subsystem is typically a "resource controller" that
52 schedules a resource or applies per-cgroup limits, but it may be
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
58 hierarchy, and a set of subsystems; each subsystem has system-specific
63 cgroups. Each hierarchy is a partition of all tasks in the system.
67 which cgroup a task is assigned, and list the task PIDs assigned to
68 a cgroup. Those creations and assignments only affect the hierarchy
74 accounting/limiting the resources which processes in a cgroup can
76 you to associate a set of CPUs and a set of memory nodes with the
85 namespaces. These all require the basic notion of a
98 hierarchy to be a natural division of tasks, without having to handle
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)
108 that can benefit from multiple hierarchies, consider a large
120 that they can run anywhere) with a limit of 20%
138 the admin can easily set up a script which receives exec notifications
143 With only a single hierarchy, he now would potentially have to create
144 a separate cgroup for every browser launched and associate it with
149 access temporarily to a student's browser (since it is night and the user
153 With ability to write PIDs directly to resource classes, it's just a
171 - Each task in the system has a reference-counted pointer to a
174 - A css_set contains a set of reference-counted pointers to
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
192 The implementation of cgroups requires a few, simple hooks
198 - in fork and exit, to attach and detach a task from its css_set.
200 In addition, a new file system of type "cgroup" may be mounted, to
202 kernel. When mounting a cgroup hierarchy, you may specify a
205 mount a hierarchy containing all registered subsystems.
210 hierarchy, the mount will fail with -EBUSY. Otherwise, a new hierarchy
213 It's not currently possible to bind a new subsystem to an active
214 cgroup hierarchy, or to unbind a subsystem from an active cgroup
218 When a cgroup filesystem is unmounted, if there are any
230 Each cgroup is represented by a directory in the cgroup file system
234 is not guaranteed to be sorted. Writing a thread ID into this file
239 Writing a thread group ID into this file moves all threads in that
249 command. The properties of a cgroup, such as its flags, are
254 a large system into nested, dynamically changeable, "soft-partitions".
257 children of that task, to a cgroup allows organizing the work load
258 on a system into related sets of tasks. A task may be re-attached to
262 When a task is moved from one cgroup to another, it gets a new
264 desired collection of cgroups then that group is reused, otherwise a new
266 looking into a hash table.
268 To allow access from a cgroup to the css_sets (and hence tasks)
269 that comprise it, a set of cg_cgroup_link objects form a lattice;
270 each cg_cgroup_link is linked into a list of cg_cgroup_links for
271 a single cgroup on its cgrp_link_list field, and a list of
272 cg_cgroup_links for a single css_set on its cg_link_list.
274 Thus the set of tasks in a cgroup can be listed by iterating over
278 The use of a Linux virtual file system (vfs) to represent the
279 cgroup hierarchy provides for a familiar permission and name space
280 for cgroups, with a minimum of additional kernel code.
285 If the notify_on_release flag is enabled (1) in a cgroup, then
296 a cgroup hierarchy's release_agent path is empty.
302 flag is enabled (1) in a cgroup, a new cpuset cgroup will copy its
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.
321 For example, the following sequence of commands will setup a cgroup
323 and then start a subshell 'sh' in that cgroup:
348 To mount a cgroup hierarchy with all available subsystems, type:
360 resources you want to control. Therefore, you should mount a tmpfs on
367 To mount a cgroup hierarchy with just the cpuset and memory
378 To Specify a hierarchy's release_agent:
385 when the hierarchy consists of a single (root) cgroup. Supporting
389 Then under /sys/fs/cgroup/rg1 you can find a tree that corresponds to the
398 If you want to create a new cgroup under /sys/fs/cgroup/rg1:
417 To remove a cgroup, just use rmdir:
429 Note that it is PID, not PIDs. You can only attach ONE task at a time.
442 threads in a threadgroup at once. Echoing the PID of any task in a
447 Note: Since every task is always a member of exactly one cgroup in each
448 mounted hierarchy, to remove a task from its current cgroup you must
449 move it into a new cgroup (possibly the root cgroup) by writing to the
453 a process to another cgroup can fail.
458 Passing the name=<x> option when mounting a cgroups hierarchy
460 mounting a pre-existing hierarchy, in order to refer to it by name
462 nameless, or has a unique name.
466 When passing a name=<x> option for a new hierarchy, you need to
469 you give a subsystem a name.
482 system needs to create a cgroup_subsys object. This contains
484 with a subsystem ID which will be assigned by the cgroup system.
488 - subsys_id: a unique array index for the subsystem, indicating which
491 - name: should be initialized to a unique subsystem name. Should be
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
515 Accessing a task's cgroup pointer may be done in the following ways:
526 - define a cgroup_subsys object called <name>_subsys
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
540 Called to allocate a subsystem state object for a cgroup. The
542 cgroup, returning a pointer to the new object on success or a
544 a structure of type cgroup_subsys_state (typically embedded in a
548 identified by the passed cgroup object having a NULL parent (since
578 be called for a newly-created cgroup if an error occurs after this
584 Called prior to moving one or more tasks into a cgroup; if the
597 cgroup_taskset_for_each() iterator. Note that this isn't called on a
607 when a subsystem is disabled on a cgroup through
609 subsystems depend on it. cgroup core makes such a css invisible by
612 This prevents unexpected resource control from a hidden css and
619 Called when a task attach operation has failed after can_attach() has succeeded.
621 function, so that the subsystem can implement a rollback. If not, not necessary.
634 Called when a task is forked into a cgroup.
643 Called when a cgroup subsystem is rebound to a different hierarchy
645 the default hierarchy (which never has sub-cgroups) and a hierarchy
664 in containers and systemd for assorted meta data like main PID in a cgroup
665 (systemd creates a cgroup per service).
673 able to tell whether a command succeeded or failed.