Differences

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

--- kernel:control_groups [2020/07/21 22:54] – old revision restored (2017/04/06 10:38) 192.99.10.47
+++ kernel:control_groups [2020/07/22 18:05] (current) – old revision restored (2020/07/20 16:09) 207.244.157.10
@@ Line 299: / 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.
-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 ====
@@ Line 316: / Line 316: @@
 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 =====
@@ Line 323: / Line 324: @@
 ==== 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:
@@ Line 336: / Line 337: @@
 ==== 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.
-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: