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 explanatory consequences of those rules.
Any single subsystem (such as cpu
) can be attached to at most one hierarchy.
As a consequence, the cpu
subsystem can never be attached to two different hierarchies.
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.
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 is made 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_and_mem
, 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_and_mem
, and any one cgroup in net
.
The cgroup in cpu_and_mem
that the http
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 it is a member of might limit its transmission rate to 30
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 control groups, therefore, every system task is always in at least one cgroup.
Any process (task) on the system which forks itself creates a child process (task). The child task automatically becomes members of all of the cgroups its parent is members of. The child task can then be moved to different cgroups as needed, but initially, it always inherits the cgroups (the "environment" in process terminology) of its parent task.
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 inherit memberships to the exact same cgroups as their parent task, but those memberships can be changed or removed later.