Wiki

User Tools

Site Tools

Trace: • start • const_auto_ptr • pf_packet_filter_firewall • parallel_ports_directory
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 16:50] – old revision restored (2017/04/06 10:33) 91.121.7.147kernel:control_groups [2020/07/22 18:05] (current) – old revision restored (2020/07/20 16:09) 207.244.157.10
Line 131: Line 131:
 ===== What does notify_on_release do? ===== ===== What does notify_on_release do? =====
  
-If the notify_on_release flag is enabled (1) in a cgroup, then whenever the last task in the cgroup leaves (exits or attaches to some other cgroup) and the last child cgroup of that cgroup is removed, then the kernel runs the command specified by the contents of the "release_agent" file in that hierarchy's root directory, supplying the pathname (relative to the mount point of the cgroup file system) of the abandoned cgroup.  This enables automatic removal of abandoned cgroups.  The default value of notify_on_release in the root cgroup at system boot is disabled (0).  The default value of other cgroups at creation is the current value of their parents notify_on_release setting. The default value of a cgroup hierarchy's release_agent path is empty.+If the **notify_on_release** flag is enabled (1) in a cgroup, then whenever the last task in the cgroup leaves (exits or attaches to some other cgroup) and the last child cgroup of that cgroup is removed, then the kernel runs the command specified by the contents of the **"release_agent"** file in that hierarchy's root directory, supplying the pathname (relative to the mount point of the cgroup file system) of the abandoned cgroup.  This enables automatic removal of abandoned cgroups.  The default value of notify_on_release in the root cgroup at system boot is disabled (0).  The default value of other cgroups at creation is the current value of their parents notify_on_release setting. The default value of a cgroup hierarchy's release_agent path is empty.
  
  
 ===== What does clone_children do? ===== ===== What does clone_children do? =====
  
-If the clone_children flag is enabled (1) in a cgroup, then all cgroups created beneath will call the post_clone callbacks for each subsystem of the newly created cgroup. Usually when this callback is implemented for a subsystem, it copies the values of the parent subsystem, this is the case for the cpuset.+If the **clone_children** flag is enabled (1) in a cgroup, then all cgroups created beneath will call the post_clone callbacks for each subsystem of the newly created cgroup. Usually when this callback is implemented for a subsystem, it copies the values of the parent subsystem, this is the case for the cpuset.
  
  
Line 143: Line 143:
 To start a new job that is to be contained within a cgroup, using the "cpuset" cgroup subsystem, the steps are something like: To start a new job that is to be contained within a cgroup, using the "cpuset" cgroup subsystem, the steps are something like:
  
- 1) mkdir /dev/cgroup +  - mkdir /dev/cgroup 
- 2) mount -t cgroup -ocpuset cpuset /dev/cgroup +  - mount -t cgroup -ocpuset cpuset /dev/cgroup 
- 3) Create the new cgroup by doing mkdir's and write's (or echo's) in +  - Create the new cgroup by doing mkdir's and write's (or echo's) in the /dev/cgroup virtual file system. 
-    the /dev/cgroup virtual file system. +  - Start a task that will be the "founding father" of the new job. 
- 4) Start a task that will be the "founding father" of the new job. +  - Attach that task to the new cgroup by writing its pid to the /dev/cgroup tasks file for that cgroup. 
- 5) Attach that task to the new cgroup by writing its pid to the +  - fork, exec or clone the job tasks from this founding father task.
-    /dev/cgroup tasks file for that cgroup. +
- 6) fork, exec or clone the job tasks from this founding father task.+
  
 For example, the following sequence of commands will setup a cgroup named "Charlie", containing just CPUs 2 and 3, and Memory Node 1, and then start a subshell 'sh' in that cgroup: For example, the following sequence of commands will setup a cgroup named "Charlie", containing just CPUs 2 and 3, and Memory Node 1, and then start a subshell 'sh' in that cgroup:
Line 181: 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 214: 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 241: 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 275: 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 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. 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 316: 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 323: 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 336: 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.1595350235.txt.gz · Last modified: 2020/07/21 16:50 by 91.121.7.147
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki