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/22 11:47] – old revision restored (2017/04/06 10:27) 204.12.220.106kernel:control_groups [2020/07/22 18:05] (current) – old revision restored (2020/07/20 16:09) 207.244.157.10
Line 78: Line 78:
 Control Groups extends the kernel as follows: Control Groups extends the kernel as follows:
  
-  * Each task in the system has a reference-counted pointer to a css_set.+  * Each task in the system has a reference-counted pointer to a **css_set**.
  
-  * A css_set contains a set of reference-counted pointers to cgroup_subsys_state objects, one for each cgroup subsystem registered in the system.  There is no direct link from a task to the cgroup of which it's a member in each hierarchy, but this can be determined by following pointers through the cgroup_subsys_state objects. This is because accessing the subsystem state is something that's expected to happen frequently and in performance-critical code, whereas operations that require a task's actual cgroup assignments (in particular, moving between cgroups) are less common. A linked list runs through the cg_list field of each task_struct using the css_set, anchored at css_set->tasks.+  * A **css_set** contains a set of reference-counted pointers to **cgroup_subsys_state** objects, one for each cgroup subsystem registered in the system.  There is no direct link from a task to the cgroup of which it's a member in each hierarchy, but this can be determined by following pointers through the cgroup_subsys_state objects. This is because accessing the subsystem state is something that's expected to happen frequently and in performance-critical code, whereas operations that require a task's actual cgroup assignments (in particular, moving between cgroups) are less common. A linked list runs through the cg_list field of each task_struct using the css_set, anchored at css_set->tasks.
  
   * A cgroup hierarchy filesystem can be mounted  for browsing and manipulation from user space.   * A cgroup hierarchy filesystem can be mounted  for browsing and manipulation from user space.
Line 95: Line 95:
  
 If an active hierarchy with exactly the same set of subsystems already exists, it will be reused for the new mount.  If no existing hierarchy If an active hierarchy with exactly the same set of subsystems already exists, it will be reused for the new mount.  If no existing hierarchy
-matches, and any of the requested subsystems are in use in an existing hierarchy, the mount will fail with -EBUSY. Otherwise, a new hierarchy +matches, and any of the requested subsystems are in use in an existing hierarchy, the mount will fail with **-EBUSY**.  Otherwise, a new hierarchy is activated, associated with the requested subsystems.
-is activated, associated with the requested subsystems.+
  
-It's not currently possible to bind a new subsystem to an active cgroup hierarchy, or to unbind a subsystem from an active cgroup hierarchy. This may be possible in future, but is fraught with nasty error-recovery issues.+It's not currently possible to bind a new subsystem to an active cgroup hierarchy, or to unbind a subsystem from an active cgroup hierarchy.  This may be possible in future, but is fraught with nasty error-recovery issues.
  
 When a cgroup filesystem is unmounted, if there are any child cgroups created below the top-level cgroup, that hierarchy will remain active even though unmounted; if there are no child cgroups then the hierarchy will be deactivated. When a cgroup filesystem is unmounted, if there are any child cgroups created below the top-level cgroup, that hierarchy will remain active even though unmounted; if there are no child cgroups then the hierarchy will be deactivated.
Line 111: Line 110:
   * **cgroup.procs**: list of tgids in the cgroup.  This list is not guaranteed to be sorted or free of duplicate tgids, and userspace should sort/uniquify the list if this property is required.  This is a read-only file, for now.   * **cgroup.procs**: list of tgids in the cgroup.  This list is not guaranteed to be sorted or free of duplicate tgids, and userspace should sort/uniquify the list if this property is required.  This is a read-only file, for now.
   * **notify_on_release** flag: run the release agent on exit?   * **notify_on_release** flag: run the release agent on exit?
-  * **release_agent**: the path to use for release notifications (this file exists in the top cgroup only)+  * **release_agent**: the path to use for release notifications (this file exists in the top cgroup only).
  
-Other subsystems such as cpusets may add additional files in each cgroup dir.+Other subsystems such as [[Kernel:CPU Sets|cpusets]] may add additional files in each cgroup dir.
  
 New cgroups are created using the mkdir system call or shell command.  The properties of a cgroup, such as its flags, are modified by writing to the appropriate file in that cgroups directory, as listed above. New cgroups are created using the mkdir system call or shell command.  The properties of a cgroup, such as its flags, are modified by writing to the appropriate file in that cgroups directory, as listed above.
Line 121: Line 120:
 The attachment of each task, automatically inherited at fork by any children of that task, to a cgroup allows organizing the work load on a system into related sets of tasks.  A task may be re-attached to any other cgroup, if allowed by the permissions on the necessary cgroup file system directories. The attachment of each task, automatically inherited at fork by any children of that task, to a cgroup allows organizing the work load on a system into related sets of tasks.  A task may be re-attached to any other cgroup, if allowed by the permissions on the necessary cgroup file system directories.
  
-When a task is moved from one cgroup to another, it gets a new css_set pointer - if there's an already existing css_set with the desired collection of cgroups then that group is reused, else a new css_set is allocated. The appropriate existing css_set is located by looking into a hash table.+When a task is moved from one cgroup to another, it gets a new **css_set** pointer - if there's an already existing css_set with the desired collection of cgroups then that group is reused, else a new css_set is allocated. The appropriate existing css_set is located by looking into a hash table.
  
-To allow access from a cgroup to the css_sets (and hence tasks) that comprise it, a set of cg_cgroup_link objects form a lattice; each cg_cgroup_link is linked into a list of cg_cgroup_links for a single cgroup on its cgrp_link_list field, and a list of cg_cgroup_links for a single css_set on its cg_link_list.+To allow access from a cgroup to the css_sets (and hence tasks) that comprise it, a set of **cg_cgroup_link** objects form a lattice; each cg_cgroup_link is linked into a list of **cg_cgroup_links** for a single cgroup on its **cgrp_link_list** field, and a list of cg_cgroup_links for a single css_set on its **cg_link_list**.
  
 Thus the set of tasks in a cgroup can be listed by iterating over each css_set that references the cgroup, and sub-iterating over each css_set's task set. Thus the set of tasks in a cgroup can be listed by iterating over each css_set that references the cgroup, and sub-iterating over each css_set's task set.
Line 132: 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 144: 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 182: 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 215: 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 242: 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 276: 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 300: 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 317: 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 324: 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 337: 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.1595418435.txt.gz · Last modified: 2020/07/22 11:47 by 204.12.220.106
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki