Red Hat Training
A Red Hat training course is available for Red Hat Enterprise Linux
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.
A single hierarchy can have one or more subsystems attached to it.
As a consequence, the
memorysubsystems (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
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
cpusubsystem can never be attached to two different hierarchies if one of those hierarchies already has the
memorysubsystem 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.
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
memorysubsystems are attached to a hierarchy named
cpu_mem_cg, and the
net_clssubsystem is attached to a hierarchy named
net, then a running
httpdprocess could be a member of any one cgroup in
cpu_mem_cg, and any one cgroup in
The cgroup in
httpdprocess 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
1024MB. Additionally, the cgroup in
httpdprocess is a member of might limit its transmission rate to
30MB/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
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
httpdtask that is a member of the cgroup named
cpu_and_memhierarchy, and a member of the cgroup
nethierarchy. When that
httpdprocess forks itself, its child process automatically becomes a member of the
half_cpu_1gb_maxcgroup, and the
trans_rate_30cgroup. 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.