User Tools

Site Tools


kernel:control_groups

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
kernel:control_groups [2020/07/21 22:53] – old revision restored (2017/04/06 10:35) 192.99.10.47kernel:control_groups [2020/07/22 18:05] (current) – old revision restored (2020/07/20 16:09) 207.244.157.10
Line 179: Line 179:
 </code> </code>
  
-The "xxx" is not interpreted by the cgroup code, but will appear in /proc/mounts so may be any useful identifying string that you like.+The "xxx" is not interpreted by the cgroup code, but will appear in **/proc/mounts** so may be any useful identifying string that you like.
  
 To mount a cgroup hierarchy with just the cpuset and memory subsystems, type: To mount a cgroup hierarchy with just the cpuset and memory subsystems, type:
Line 212: Line 212:
 Note that changing the set of subsystems is currently only supported when the hierarchy consists of a single (root) cgroup.  Supporting the ability to arbitrarily bind/unbind subsystems from an existing cgroup hierarchy is intended to be implemented in the future. Note that changing the set of subsystems is currently only supported when the hierarchy consists of a single (root) cgroup.  Supporting the ability to arbitrarily bind/unbind subsystems from an existing cgroup hierarchy is intended to be implemented in the future.
  
-Then under /dev/cgroup you can find a tree that corresponds to the tree of the cgroups in the system. For instance, /dev/cgroup is the cgroup that holds the whole system.+Then under **/dev/cgroup** you can find a tree that corresponds to the tree of the cgroups in the system. For instance, /dev/cgroup is the cgroup that holds the whole system.
  
 If you want to change the value of release_agent: If you want to change the value of release_agent:
Line 239: Line 239:
 <code bash> <code bash>
 ls ls
-<+
 cgroup.procs notify_on_release tasks cgroup.procs notify_on_release tasks
 (plus whatever files added by the attached subsystems) (plus whatever files added by the attached subsystems)
Line 273: Line 273:
 </code> </code>
  
-Note that it is PID, not PIDs.  You can only attach ONE task at a time.  If you have several tasks to attach, you have to do it one after another:+<WRAP info> 
 +**NOTE:**  It is PID, not PIDs.  You can only attach ONE task at a time.  If you have several tasks to attach, you have to do it one after another: 
 +</WRAP>
  
 <code bash> <code bash>
Line 297: Line 299:
 When passing a name=<x> option for a new hierarchy, you need to specify subsystems manually; the legacy behaviour of mounting all subsystems when none are explicitly specified is not supported when you give a subsystem a name. When passing a name=<x> option for a new hierarchy, you need to specify subsystems manually; the legacy behaviour of mounting all subsystems when none are explicitly specified is not supported when you give a subsystem a name.
  
-The name of the subsystem appears as part of the hierarchy description in /proc/mounts and /proc/<pid>/cgroups.+The name of the subsystem appears as part of the hierarchy description in **/proc/mounts** and **/proc/<pid>/cgroups**.
  
 ==== Notification API ==== ==== Notification API ====
Line 314: Line 316:
 To unregister notification handler just close eventfd. To unregister notification handler just close eventfd.
  
-NOTE: Support of notifications should be implemented for the control file.  See documentation for the subsystem. +<WRAP info> 
 +**NOTE** Support of notifications should be implemented for the control file.  See documentation for the subsystem. 
 +</WRAP>
  
 ===== Kernel API ===== ===== Kernel API =====
Line 321: Line 324:
 ==== Overview ==== ==== Overview ====
  
-Each kernel subsystem that wants to hook into the generic cgroup system needs to create a cgroup_subsys object.  This contains various methods, which are callbacks from the cgroup system, along with a subsystem id which will be assigned by the cgroup system.+Each kernel subsystem that wants to hook into the generic cgroup system needs to create a **cgroup_subsys** object.  This contains various methods, which are callbacks from the cgroup system, along with a subsystem id which will be assigned by the cgroup system.
  
 Other fields in the cgroup_subsys object include: Other fields in the cgroup_subsys object include:
Line 334: Line 337:
 ==== Synchronization ==== ==== Synchronization ====
  
-There is a global mutex, cgroup_mutex, used by the cgroup system.  This should be taken by anything that wants to modify a cgroup.  It may also be taken to prevent cgroups from being modified, but more specific locks may be more appropriate in that situation.+There is a global mutex, **cgroup_mutex**, used by the cgroup system.  This should be taken by anything that wants to modify a cgroup.  It may also be taken to prevent cgroups from being modified, but more specific locks may be more appropriate in that situation.
  
 See kernel/cgroup.c for more details. See kernel/cgroup.c for more details.
  
-Subsystems can take/release the cgroup_mutex via the functions cgroup_lock()/cgroup_unlock().+Subsystems can take/release the cgroup_mutex via the functions **cgroup_lock()**/**cgroup_unlock()**.
  
 Accessing a task's cgroup pointer may be done in the following ways: Accessing a task's cgroup pointer may be done in the following ways:
kernel/control_groups.1595372026.txt.gz · Last modified: 2020/07/21 22:53 by 192.99.10.47

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki