1.2. Relationships Between Subsystems, Hierarchies, Control Groups and Tasks
1.2. Relationships Between Subsystems, Hierarchies, Control Groups and Tasks Remember that system processes are called tasks in cgroup terminology. Here are a few simple rules governing the relationships between subsystems, hierarchies of cgroups, and tasks, along with explanations of the consequences of those rules. Rule 1 A single hierarchy can have one or more subsystems attached to it. As a consequence, the cpu and memory subsystems (or any number of subsystems) can be attached to a single hierarchy, as long as each one is not attached to any other hierarchy which has any other subsystems attached to it already (see Rule 2). Figure 1.1. Rule 1 Rule 2 Any single subsystem (such as cpu ) cannot be attached to more than one hierarchy if one of those hierarchies has a different subsystem attached to it already. As a consequence, the cpu subsystem can never be attached to two different hierarchies if one of those hierarchies already has the memory subsystem attached to it. However, a single subsystem can be attached to two hierarchies if both of those hierarchies have only that subsystem attached. Figure 1.2. Rule 2-The numbered bullets represent a time sequence in which the subsystems are attached. Rule 3 Each time a new hierarchy is created on the systems, all tasks on the system are initially members of the default cgroup of that hierarchy, which is known as the root cgroup . For any single hierarchy you create, each task on the system can be a member of exactly one cgroup in that hierarchy. A single task may be in multiple cgroups, as long as each of those cgroups is in a different hierarchy. As soon as a task becomes a member of a second cgroup in the same hierarchy, it is removed from the first cgroup in that hierarchy. At no time is a task ever in two different cgroups in the same hierarchy. As a consequence, if the cpu and memory subsystems are attached to a hierarchy named cpu_mem_cg , and the net_cls subsystem is attached to a hierarchy named net , then a running httpd process could be a member of any one cgroup in cpu_mem_cg , and any one cgroup in net . The cgroup in cpu_mem_cg that the httpd process is a member of might restrict its CPU time to half of that allotted to other processes, and limit its memory usage to a maximum of 1024 MB. Additionally, the cgroup in net that the httpd process is a member of might limit its transmission rate to 30 MB/s (megabytes per second). When the first hierarchy is created, every task on the system is a member of at least one cgroup: the root cgroup. When using cgroups, therefore, every system task is always in at least one cgroup. Figure 1.3. Rule 3 Rule 4 Any process (task) on the system which forks itself creates a child task. A child task automatically inherits the cgroup membership of its parent but can be moved to different cgroups as needed. Once forked, the parent and child processes are completely independent. As a consequence, consider the httpd task that is a member of the cgroup named half_cpu_1gb_max in the cpu_and_mem hierarchy, and a member of the cgroup trans_rate_30 in the net hierarchy. When that httpd process forks itself, its child process automatically becomes a member of the half_cpu_1gb_max cgroup, and the trans_rate_30 cgroup. It inherits the exact same cgroups its parent task belongs to. From that point forward, the parent and child tasks are completely independent of each other: changing the cgroups that one task belongs to does not affect the other. Neither will changing cgroups of a parent task affect any of its grandchildren in any way. To summarize: any child task always initially inherits memberships to the exact same cgroups as their parent task, but those memberships can be changed or removed later. Figure 1.4. Rule 4-The numbered bullets represent a time sequence in which the task forks.