Lines Matching +full:resource +full:- +full:files
6 Documentation/admin-guide/cgroup-v1/cpusets.rst
12 Portions Copyright (c) 2004-2006 Silicon Graphics, Inc.
42 ----------------------
55 particular ways. A subsystem is typically a "resource controller" that
56 schedules a resource or applies per-cgroup limits, but it may be
62 hierarchy, and a set of subsystems; each subsystem has system-specific
69 User-level code may create and destroy cgroups by name in an
79 access. For example, cpusets (see Documentation/admin-guide/cgroup-v1/cpusets.rst) allow
84 ----------------------------
87 Linux kernel, mainly for resource-tracking purposes. Such efforts
101 different subsystems - having parallel hierarchies allows each
107 At one extreme, each resource controller or subsystem could be in a
113 university server with various users - students, professors, system
114 tasks etc. The resource planning for this server could be along the
141 (by putting those resource subsystems in different hierarchies),
149 appropriate network and other resource class. This may lead to
157 With ability to write PIDs directly to resource classes, it's just a
166 new resource classes.
171 ---------------------------------
175 - Each task in the system has a reference-counted pointer to a
178 - A css_set contains a set of reference-counted pointers to
185 and in performance-critical code, whereas operations that require a
189 css_set->tasks.
191 - A cgroup hierarchy filesystem can be mounted for browsing and
194 - You can list all the tasks (by PID) attached to any cgroup.
197 into the rest of the kernel, none in performance-critical paths:
199 - in init/main.c, to initialize the root cgroups and initial
202 - in fork and exit, to attach and detach a task from its css_set.
207 comma-separated list of subsystems to mount as the filesystem mount
214 hierarchy, the mount will fail with -EBUSY. Otherwise, a new hierarchy
220 error-recovery issues.
223 child cgroups created below the top-level cgroup, that hierarchy
227 No new system calls are added for cgroups - all support for
235 containing the following files describing that cgroup:
237 - tasks: list of tasks (by PID) attached to that cgroup. This list
240 - cgroup.procs: list of thread group IDs in the cgroup. This list is
245 - notify_on_release flag: run the release agent on exit?
246 - release_agent: the path to use for release notifications (this file
249 Other subsystems such as cpusets may add additional files in each
258 a large system into nested, dynamically changeable, "soft-partitions".
262 on a system into related sets of tasks. A task may be re-attached to
267 css_set pointer - if there's an already existing css_set with the
279 each css_set that references the cgroup, and sub-iterating over
287 ------------------------------------
303 ---------------------------------
310 --------------------------
315 1) mount -t tmpfs cgroup_root /sys/fs/cgroup
317 3) mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset
329 mount -t tmpfs cgroup_root /sys/fs/cgroup
331 mount -t cgroup cpuset -ocpuset /sys/fs/cgroup/cpuset
335 /bin/echo 2-3 > cpuset.cpus
347 ---------------
354 # mount -t cgroup xxx /sys/fs/cgroup
360 if cpusets are enabled the user will have to populate the cpus and mems files
364 different hierarchies of cgroups for each single resource or group of
366 /sys/fs/cgroup and create directories for each cgroup resource or resource
369 # mount -t tmpfs cgroup_root /sys/fs/cgroup
375 # mount -t cgroup -o cpuset,memory hier1 /sys/fs/cgroup/rg1
386 # mount -t cgroup -o cpuset,release_agent="/sbin/cpuset_release_agent" \
415 In this directory you can find several files::
419 (plus whatever files added by the attached subsystems)
435 has processes attached, or is held alive by other subsystem-specific
439 -----------------------
472 --------------------------------
476 mounting a pre-existing hierarchy, in order to refer to it by name
480 The name should match [\w.-]+
495 ------------
504 - subsys_id: a unique array index for the subsystem, indicating which
505 entry in cgroup->subsys[] this subsystem should be managing.
507 - name: should be initialized to a unique subsystem name. Should be
510 - early_init: indicate if the subsystem needs early initialization
518 -------------------
532 - while holding cgroup_mutex
533 - while holding the task's alloc_lock (via task_lock())
534 - inside an rcu_read_lock() section via rcu_dereference()
537 -----------------
541 - add an entry in linux/cgroup_subsys.h
542 - define a cgroup_subsys object called <name>_cgrp_subsys
546 be successful no-ops.
556 larger subsystem-specific object), which will be initialized by the
568 subsystem may choose to fail creation by returning -errno. This
580 cgroup removal will proceed to the next step - css_free(). After this
588 is completely unused; @cgrp->parent is still valid. (Note - can also
589 be called for a newly-created cgroup if an error occurs after this
601 - it's guaranteed that all are from the same thread group
602 - @tset contains all tasks from the thread group whether or not
604 - the first task is the leader
621 removing the associated interface files and invokes this callback so
623 This prevents unexpected resource control from a hidden css and
631 A subsystem whose can_attach() has some side-effects should provide this
640 post-attachment activity that requires memory allocations or blocking.
660 the default hierarchy (which never has sub-cgroups) and a hierarchy
661 that is being created/destroyed (and hence has no sub-cgroups).
667 directories and files. The current supported types are:
669 - Trusted (XATTR_TRUSTED)
670 - Security (XATTR_SECURITY)