Lines Matching refs:cgroup
6 Documentation/admin-guide/cgroup-v1/cpusets.rst
50 A *cgroup* associates a set of tasks with a set of parameters for one
56 schedules a resource or applies per-cgroup limits, but it may be
63 state attached to each cgroup in the hierarchy. Each hierarchy has
64 an instance of the cgroup virtual filesystem associated with it.
70 instance of the cgroup virtual file system, specify and query to
71 which cgroup a task is assigned, and list the task PIDs assigned to
72 a cgroup. Those creations and assignments only affect the hierarchy
73 associated with that instance of the cgroup file system.
77 cgroup support to provide new attributes for cgroups, such as
78 accounting/limiting the resources which processes in a cgroup can
79 access. For example, cpusets (see Documentation/admin-guide/cgroup-v1/cpusets.rst) allow
81 tasks in each cgroup.
93 up in the same group (cgroup) as their parent process.
95 The kernel cgroup patch provides the minimum essential kernel
147 # echo browser_pid > /sys/fs/cgroup/<restype>/<userclass>/tasks
150 a separate cgroup for every browser launched and associate it with
162 # echo pid > /sys/fs/cgroup/network/<new_class>/tasks
164 # echo pid > /sys/fs/cgroup/network/<orig_class>/tasks
166 Without this ability, the administrator would have to split the cgroup into
181 cgroup_subsys_state objects, one for each cgroup subsystem
183 the cgroup of which it's a member in each hierarchy, but this
188 task's actual cgroup assignments (in particular, moving between
193 - A cgroup hierarchy filesystem can be mounted for browsing and
196 - You can list all the tasks (by PID) attached to any cgroup.
206 In addition, a new file system of type "cgroup" may be mounted, to
208 kernel. When mounting a cgroup hierarchy, you may specify a
210 options. By default, mounting the cgroup filesystem attempts to
220 cgroup hierarchy, or to unbind a subsystem from an active cgroup
224 When a cgroup filesystem is unmounted, if there are any
225 child cgroups created below the top-level cgroup, that hierarchy
230 querying and modifying cgroups is via this cgroup file system.
232 Each task under /proc has an added file named 'cgroup' displaying,
233 for each active hierarchy, the subsystem names and the cgroup name
234 as the path relative to the root of the cgroup file system.
236 Each cgroup is represented by a directory in the cgroup file system
237 containing the following files describing that cgroup:
239 - tasks: list of tasks (by PID) attached to that cgroup. This list
241 moves the thread into this cgroup.
242 - cgroup.procs: list of thread group IDs in the cgroup. This list is
246 group into this cgroup.
249 exists in the top cgroup only)
252 cgroup dir.
255 command. The properties of a cgroup, such as its flags, are
263 children of that task, to a cgroup allows organizing the work load
265 any other cgroup, if allowed by the permissions on the necessary
266 cgroup file system directories.
268 When a task is moved from one cgroup to another, it gets a new
274 To allow access from a cgroup to the css_sets (and hence tasks)
277 a single cgroup on its cgrp_link_list field, and a list of
280 Thus the set of tasks in a cgroup can be listed by iterating over
281 each css_set that references the cgroup, and sub-iterating over
285 cgroup hierarchy provides for a familiar permission and name space
291 If the notify_on_release flag is enabled (1) in a cgroup, then
292 whenever the last task in the cgroup leaves (exits or attaches to
293 some other cgroup) and the last child cgroup of that cgroup
296 supplying the pathname (relative to the mount point of the cgroup
297 file system) of the abandoned cgroup. This enables automatic
299 notify_on_release in the root cgroup at system boot is disabled
302 a cgroup hierarchy's release_agent path is empty.
308 flag is enabled (1) in a cgroup, a new cpuset cgroup will copy its
314 To start a new job that is to be contained within a cgroup, using
315 the "cpuset" cgroup subsystem, the steps are something like::
317 1) mount -t tmpfs cgroup_root /sys/fs/cgroup
318 2) mkdir /sys/fs/cgroup/cpuset
319 3) mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset
320 4) Create the new cgroup by doing mkdir's and write's (or echo's) in
321 the /sys/fs/cgroup/cpuset virtual file system.
323 6) Attach that task to the new cgroup by writing its PID to the
324 /sys/fs/cgroup/cpuset tasks file for that cgroup.
327 For example, the following sequence of commands will setup a cgroup
329 and then start a subshell 'sh' in that cgroup::
331 mount -t tmpfs cgroup_root /sys/fs/cgroup
332 mkdir /sys/fs/cgroup/cpuset
333 mount -t cgroup cpuset -ocpuset /sys/fs/cgroup/cpuset
334 cd /sys/fs/cgroup/cpuset
341 # The subshell 'sh' is now running in cgroup Charlie
343 cat /proc/self/cgroup
351 Creating, modifying, using cgroups can be done through the cgroup
354 To mount a cgroup hierarchy with all available subsystems, type::
356 # mount -t cgroup xxx /sys/fs/cgroup
358 The "xxx" is not interpreted by the cgroup code, but will appear in
363 for each new cgroup created before that group can be used.
368 /sys/fs/cgroup and create directories for each cgroup resource or resource
371 # mount -t tmpfs cgroup_root /sys/fs/cgroup
372 # mkdir /sys/fs/cgroup/rg1
374 To mount a cgroup hierarchy with just the cpuset and memory
377 # mount -t cgroup -o cpuset,memory hier1 /sys/fs/cgroup/rg1
388 # mount -t cgroup -o cpuset,release_agent="/sbin/cpuset_release_agent" \
389 xxx /sys/fs/cgroup/rg1
394 when the hierarchy consists of a single (root) cgroup. Supporting
396 cgroup hierarchy is intended to be implemented in the future.
398 Then under /sys/fs/cgroup/rg1 you can find a tree that corresponds to the
399 tree of the cgroups in the system. For instance, /sys/fs/cgroup/rg1
400 is the cgroup that holds the whole system.
404 # echo "/sbin/new_release_agent" > /sys/fs/cgroup/rg1/release_agent
408 If you want to create a new cgroup under /sys/fs/cgroup/rg1::
410 # cd /sys/fs/cgroup/rg1
413 Now you want to do something with this cgroup:
420 cgroup.procs notify_on_release tasks
423 Now attach your shell to this cgroup::
427 You can also create cgroups inside your cgroup by using mkdir in this
432 To remove a cgroup, just use rmdir::
436 This will fail if the cgroup is in use (has cgroups inside, or
459 You can use the cgroup.procs file instead of the tasks file to move all
461 threadgroup to cgroup.procs causes all tasks in that threadgroup to be
462 attached to the cgroup. Writing 0 to cgroup.procs moves all tasks
465 Note: Since every task is always a member of exactly one cgroup in each
466 mounted hierarchy, to remove a task from its current cgroup you must
467 move it into a new cgroup (possibly the root cgroup) by writing to the
468 new cgroup's tasks file.
470 Note: Due to some restrictions enforced by some cgroup subsystems, moving
471 a process to another cgroup can fail.
499 Each kernel subsystem that wants to hook into the generic cgroup
501 various methods, which are callbacks from the cgroup system, along
502 with a subsystem ID which will be assigned by the cgroup system.
507 entry in cgroup->subsys[] this subsystem should be managing.
515 Each cgroup object created by the system has an array of pointers,
517 subsystem; the generic cgroup code will never touch this pointer.
522 There is a global mutex, cgroup_mutex, used by the cgroup
524 cgroup. It may also be taken to prevent cgroups from being
528 See kernel/cgroup.c for more details.
533 Accessing a task's cgroup pointer may be done in the following ways:
550 ``struct cgroup_subsys_state *css_alloc(struct cgroup *cgrp)``
553 Called to allocate a subsystem state object for a cgroup. The
555 cgroup, returning a pointer to the new object on success or a
559 cgroup system. Note that this will be called at initialization to
561 identified by the passed cgroup object having a NULL parent (since
565 ``int css_online(struct cgroup *cgrp)``
575 ``void css_offline(struct cgroup *cgrp);``
582 cgroup removal will proceed to the next step - css_free(). After this
585 ``void css_free(struct cgroup *cgrp)``
588 The cgroup system is about to free @cgrp; the subsystem should free
591 be called for a newly-created cgroup if an error occurs after this
592 subsystem's create() method has been called for the new cgroup).
594 ``int can_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)``
597 Called prior to moving one or more tasks into a cgroup; if the
608 Each @tset entry also contains the task's old cgroup and tasks which
609 aren't switching cgroup can be skipped easily using the
620 when a subsystem is disabled on a cgroup through
621 "cgroup.subtree_control" but should remain enabled because other
622 subsystems depend on it. cgroup core makes such a css invisible by
629 ``void cancel_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)``
638 ``void attach(struct cgroup *cgrp, struct cgroup_taskset *tset)``
641 Called after the task has been attached to the cgroup, to allow any
647 Called when a task is forked into a cgroup.
657 ``void bind(struct cgroup *root)``
660 Called when a cgroup subsystem is rebound to a different hierarchy
661 and root cgroup. Currently this will only involve movement between
668 cgroup filesystem supports certain types of extended attributes in its
676 Like in tmpfs, the extended attributes in cgroup filesystem are stored
681 The current known users for this feature are SELinux to limit cgroup usage
682 in containers and systemd for assorted meta data like main PID in a cgroup
683 (systemd creates a cgroup per service).
692 errors. If you use it in the cgroup file system, you won't be