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.
91 up in the same group (cgroup) as their parent process.
93 The kernel cgroup patch provides the minimum essential kernel
145 # echo browser_pid > /sys/fs/cgroup/<restype>/<userclass>/tasks
148 a separate cgroup for every browser launched and associate it with
160 # echo pid > /sys/fs/cgroup/network/<new_class>/tasks
162 # echo pid > /sys/fs/cgroup/network/<orig_class>/tasks
164 Without this ability, the administrator would have to split the cgroup into
179 cgroup_subsys_state objects, one for each cgroup subsystem
181 the cgroup of which it's a member in each hierarchy, but this
186 task's actual cgroup assignments (in particular, moving between
191 - A cgroup hierarchy filesystem can be mounted for browsing and
194 - You can list all the tasks (by PID) attached to any cgroup.
204 In addition, a new file system of type "cgroup" may be mounted, to
206 kernel. When mounting a cgroup hierarchy, you may specify a
208 options. By default, mounting the cgroup filesystem attempts to
218 cgroup hierarchy, or to unbind a subsystem from an active cgroup
222 When a cgroup filesystem is unmounted, if there are any
223 child cgroups created below the top-level cgroup, that hierarchy
228 querying and modifying cgroups is via this cgroup file system.
230 Each task under /proc has an added file named 'cgroup' displaying,
231 for each active hierarchy, the subsystem names and the cgroup name
232 as the path relative to the root of the cgroup file system.
234 Each cgroup is represented by a directory in the cgroup file system
235 containing the following files describing that cgroup:
237 - tasks: list of tasks (by PID) attached to that cgroup. This list
239 moves the thread into this cgroup.
240 - cgroup.procs: list of thread group IDs in the cgroup. This list is
244 group into this cgroup.
247 exists in the top cgroup only)
250 cgroup dir.
253 command. The properties of a cgroup, such as its flags, are
261 children of that task, to a cgroup allows organizing the work load
263 any other cgroup, if allowed by the permissions on the necessary
264 cgroup file system directories.
266 When a task is moved from one cgroup to another, it gets a new
272 To allow access from a cgroup to the css_sets (and hence tasks)
275 a single cgroup on its cgrp_link_list field, and a list of
278 Thus the set of tasks in a cgroup can be listed by iterating over
279 each css_set that references the cgroup, and sub-iterating over
283 cgroup hierarchy provides for a familiar permission and name space
289 If the notify_on_release flag is enabled (1) in a cgroup, then
290 whenever the last task in the cgroup leaves (exits or attaches to
291 some other cgroup) and the last child cgroup of that cgroup
294 supplying the pathname (relative to the mount point of the cgroup
295 file system) of the abandoned cgroup. This enables automatic
297 notify_on_release in the root cgroup at system boot is disabled
300 a cgroup hierarchy's release_agent path is empty.
306 flag is enabled (1) in a cgroup, a new cpuset cgroup will copy its
312 To start a new job that is to be contained within a cgroup, using
313 the "cpuset" cgroup subsystem, the steps are something like::
315 1) mount -t tmpfs cgroup_root /sys/fs/cgroup
316 2) mkdir /sys/fs/cgroup/cpuset
317 3) mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset
318 4) Create the new cgroup by doing mkdir's and write's (or echo's) in
319 the /sys/fs/cgroup/cpuset virtual file system.
321 6) Attach that task to the new cgroup by writing its PID to the
322 /sys/fs/cgroup/cpuset tasks file for that cgroup.
325 For example, the following sequence of commands will setup a cgroup
327 and then start a subshell 'sh' in that cgroup::
329 mount -t tmpfs cgroup_root /sys/fs/cgroup
330 mkdir /sys/fs/cgroup/cpuset
331 mount -t cgroup cpuset -ocpuset /sys/fs/cgroup/cpuset
332 cd /sys/fs/cgroup/cpuset
339 # The subshell 'sh' is now running in cgroup Charlie
341 cat /proc/self/cgroup
349 Creating, modifying, using cgroups can be done through the cgroup
352 To mount a cgroup hierarchy with all available subsystems, type::
354 # mount -t cgroup xxx /sys/fs/cgroup
356 The "xxx" is not interpreted by the cgroup code, but will appear in
361 for each new cgroup created before that group can be used.
366 /sys/fs/cgroup and create directories for each cgroup resource or resource
369 # mount -t tmpfs cgroup_root /sys/fs/cgroup
370 # mkdir /sys/fs/cgroup/rg1
372 To mount a cgroup hierarchy with just the cpuset and memory
375 # mount -t cgroup -o cpuset,memory hier1 /sys/fs/cgroup/rg1
386 # mount -t cgroup -o cpuset,release_agent="/sbin/cpuset_release_agent" \
387 xxx /sys/fs/cgroup/rg1
392 when the hierarchy consists of a single (root) cgroup. Supporting
394 cgroup hierarchy is intended to be implemented in the future.
396 Then under /sys/fs/cgroup/rg1 you can find a tree that corresponds to the
397 tree of the cgroups in the system. For instance, /sys/fs/cgroup/rg1
398 is the cgroup that holds the whole system.
402 # echo "/sbin/new_release_agent" > /sys/fs/cgroup/rg1/release_agent
406 If you want to create a new cgroup under /sys/fs/cgroup/rg1::
408 # cd /sys/fs/cgroup/rg1
411 Now you want to do something with this cgroup:
418 cgroup.procs notify_on_release tasks
421 Now attach your shell to this cgroup::
425 You can also create cgroups inside your cgroup by using mkdir in this
430 To remove a cgroup, just use rmdir::
434 This will fail if the cgroup is in use (has cgroups inside, or
457 You can use the cgroup.procs file instead of the tasks file to move all
459 threadgroup to cgroup.procs causes all tasks in that threadgroup to be
460 attached to the cgroup. Writing 0 to cgroup.procs moves all tasks
463 Note: Since every task is always a member of exactly one cgroup in each
464 mounted hierarchy, to remove a task from its current cgroup you must
465 move it into a new cgroup (possibly the root cgroup) by writing to the
466 new cgroup's tasks file.
468 Note: Due to some restrictions enforced by some cgroup subsystems, moving
469 a process to another cgroup can fail.
497 Each kernel subsystem that wants to hook into the generic cgroup
499 various methods, which are callbacks from the cgroup system, along
500 with a subsystem ID which will be assigned by the cgroup system.
505 entry in cgroup->subsys[] this subsystem should be managing.
513 Each cgroup object created by the system has an array of pointers,
515 subsystem; the generic cgroup code will never touch this pointer.
520 There is a global mutex, cgroup_mutex, used by the cgroup
522 cgroup. It may also be taken to prevent cgroups from being
526 See kernel/cgroup.c for more details.
531 Accessing a task's cgroup pointer may be done in the following ways:
548 ``struct cgroup_subsys_state *css_alloc(struct cgroup *cgrp)``
551 Called to allocate a subsystem state object for a cgroup. The
553 cgroup, returning a pointer to the new object on success or a
557 cgroup system. Note that this will be called at initialization to
559 identified by the passed cgroup object having a NULL parent (since
563 ``int css_online(struct cgroup *cgrp)``
573 ``void css_offline(struct cgroup *cgrp);``
580 cgroup removal will proceed to the next step - css_free(). After this
583 ``void css_free(struct cgroup *cgrp)``
586 The cgroup system is about to free @cgrp; the subsystem should free
589 be called for a newly-created cgroup if an error occurs after this
590 subsystem's create() method has been called for the new cgroup).
592 ``int can_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)``
595 Called prior to moving one or more tasks into a cgroup; if the
606 Each @tset entry also contains the task's old cgroup and tasks which
607 aren't switching cgroup can be skipped easily using the
618 when a subsystem is disabled on a cgroup through
619 "cgroup.subtree_control" but should remain enabled because other
620 subsystems depend on it. cgroup core makes such a css invisible by
627 ``void cancel_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)``
636 ``void attach(struct cgroup *cgrp, struct cgroup_taskset *tset)``
639 Called after the task has been attached to the cgroup, to allow any
645 Called when a task is forked into a cgroup.
655 ``void bind(struct cgroup *root)``
658 Called when a cgroup subsystem is rebound to a different hierarchy
659 and root cgroup. Currently this will only involve movement between
666 cgroup filesystem supports certain types of extended attributes in its
674 Like in tmpfs, the extended attributes in cgroup filesystem are stored
679 The current known users for this feature are SELinux to limit cgroup usage
680 in containers and systemd for assorted meta data like main PID in a cgroup
681 (systemd creates a cgroup per service).
690 errors. If you use it in the cgroup file system, you won't be