|
Before proceeding to the Cgroup Model, let's review the process model. On a Linux system, all processes have a common parent process: the init process, which is executed at the kernel boot, then other processes are started by the init process, and these processes are the child processes of init. In this model, all processes have a common parent process. In other words, the process model of Linux is a single inheritance hierarchical model, or tree model. Additionally, every Linux process except the init process inherits some environment variables (such as PATH environment variable).
Cgroup Model Cgroups are actually similar to processes in that cgroups are also inheritance systems, and child cgroups inherit certain attributes from their parent cgroup. The fundamental difference between the two models is that process is a single inheritance system. While a cgroup can have a variety of different inheritance systems (meaning it can have a variety of single inheritance systems, each of which does not affect each other). Some concepts of Cgroup There are four concepts in Croup. I would liken it to a duck to water in terms of ability to use Cgroup upon understanding these four concepts. • Subsystems: A subsystem is a resource controller. For example, a CPU subsystem is a controller that controls the CPU time allocation. • Hierarchies: Can be referred to as hierarchies or can be referred to as inheritance, denotes that Control Groups are organized according to the relationship of hierarchies. • Control Groups: A group of processes divided according to a certain standard. A process may be migrated from a Control Group to another Control Group, while processes in the Control Groups may be restricted by the resources in the groups. • Tasks: In Cgroup, a task is a process of a system. Subsystems In the Red_Hat_Enterprise_Linux-6 series, the following subsystems are provided by default. • blkio — this subsystem sets limits on input/output for block devices such as physical devices (disks, solid state disks, USB and so on.) • Cpu — this subsystem uses scheduler to provide cgroup tasks access to the CPU. • cpuacct — this subsystem automatically generates reports on CPU resources used by tasks in a cgroup. • cpuset — this subsystem assigns individual CPUs (on a multicore system) and memory nodes to tasks in a cgroup. • devices — this subsystem allows or denies access to devices by tasks in a cgroup. • freezer — this subsystem suspends or resumes tasks in a cgroup. • memory — this subsystem sets limits on memory use by tasks in a cgroup and automatically generates reports on memory resources used by those tasks. • net_cls — this subsystem tags network packets with a class identifier (classid) that allows the Linux traffic controller (tc) to identify packets originating from a particular cgroup task. • ns — the namespace subsystem. Relationships Between Subsystems, Hierarchies, Control Groups and Tasks This section is probably the emphasis of this article. In this section, I'll introduce four rules referring to the RedHat manual about resource management to help us to better understand the relationships between subsystems, hierarchies of cgroups, and tasks. • Rule 1, a single inheritance (a single hierarchy) can have one or more subsystems attached to it. 
In the figure above, the CPU and Memory subsystems are attached to the cpu_mem_cg hierarchy, wherein the cg1 and cg2 are two Control Groups. But we need to note that if the CPU or Memory subsystem is attached to another hierarchy, the CPU or Memory subsystem cannot be attached to the CPU or Memory subsystem. • Rule 2, a subsystem cannot be attached to more than one hierarchy. 
Actually this rule is described simply in Rule 1. The figure above shows that the CPU is attached to the cpu_cg hierarchy on the left side. It will fail to be attached when the CPU is intended to be attached to the cpu_mem_cg hierarchy. • Rule 3, each time a new hierarchy is created on the systems, another control group is created by default, which is known as the root cgroup. In the meantime all tasks (processes) on the system are members of the root cgroup. Each task on the system can be a member of exactly one control group in a hierarchy, and the task can move to another control group. But we need to note that at no time is a task ever in two different control groups in the same hierarchy, but a single task can be in two control groups in two different hierarchies. 
The figure above shows that the httpd process cannot be a member of the control groups cg1 and cg2 in Hierarchy A at the same time, but the httpd process can be a member of the control group cg1 in Hierarchy A and control group cg3 in Hierarchy B at the same time. • Rule 4, any process (task) on the system which forks itself creates a child task, and the child task automatically inherits the control group of its parent and becomes a member of the control group. The child task can be moved to other control groups later, and the parent and child tasks (processes) are completely independent. 
The figure above shows that the child process forked by the httpd process is still a member of the control group cg1. |
|
