CGroup Introduction, application examples and principle description (published in the IBM Developer Forum)

Please see: http://www.ibm.com/developerworks/cn/linux/1506_cgroup/index.htmlCGroup introduction

CGroup is the abbreviation for Control Groups, which is a mechanism provided by the Linux kernel to restrict, record, and isolate the material resources (such as CPU memory I/O) used by process groups (processes Groups). 2007 entered the Linux 2.6.24 kernel, CGroups is not a new creation, it will process management from Cpuset, the author is Google's Paul menage. CGroups is also the resource management tool that LXC uses to implement virtualization.

CGroup Function and composition

CGroup is the Linux kernel feature that manages any process in a group. CGroup itself is the infrastructure that provides the functionality and interface for grouping processes, and specific resource management functions such as I/O or memory allocation control are implemented through this function. These specific resource management functions are called CGroup subsystems or controllers. The CGroup subsystem has memory controller, control process scheduling CPU controller and so on. The Cgroup subsystem that the running kernel can use is confirmed by the/proc/cgroup.

CGroup provides a CGroup virtual file system as a user interface for group management and for each subsystem setup. To use CGroup, you must mount the CGroup file system. The mount option specifies which subsystem to use.

Types of files supported by CGroup

Table 1. Types of files supported by CGroup

file name	r/w	Use
Release_agent	RW	Delete the command executed when grouping, this file only exists root group
Notify_on_release	RW	Sets whether to perform release_agent. For 1 o'clock execution
Tasks	RW	List of threads that belong to a group
Cgroup.procs	R	The list of process PID that belong to the group. A thread that includes only multithreaded processes leader TID, which is different from tasks
Cgroup.event_control	RW	Configuration files for monitoring status changes and grouping delete events

CGroup Related Concepts Explained

1. Tasks (Task). In Cgroups, the task is a process of the system;

2. Control group. Control groups are a set of processes that are divided according to a certain standard. The resource control in Cgroups is implemented in the control group. A process can be added to a control group and migrated from one process team to another. A process group process can use Cgroups to control the allocation of resources by the population, while being subject to the cgroups to control the group-set limits;

3. Level (hierarchy). Control groups can be organized into hierarchical forms, both of which control ethnic trees. Control the child nodes in the tree group is the child of the parent control group, inheriting the specific attributes of the parent control group;

4. Subsystem (SUBSYSTEM). A subsystem is a resource controller, such as a CPU subsystem is a controller that controls CPU time allocation. Subsystems must be attached (attach) to one level to function, and when a subsystem is attached to a hierarchy, all control groups at that level are controlled by this subsystem.

Mutual relations

1. Every time a new level is created in the system, all tasks in that system are the default Cgroup of that level (what we call root Cgroup, which is created automatically when the hierarchy is created, and the cgroup that are created in that hierarchy are the descendants of this cgroup).

2. A subsystem can be attached to a maximum of one level;

3. Multiple subsystems can be attached to a hierarchy;

4. A task can be a member of multiple cgroup, but these cgroup must be at different levels;

5. When a process (task) in the system creates a child process (Task), the subtask automatically becomes a member of the Cgroup whose parent process is located. The subtask can then be moved to a different cgroup as needed, but at first it always inherits the Cgroup of its parent task.

Figure 1. CGroup Hierarchy Chart

The CGroup hierarchical relationship shown in Figure 1 shows that the CPU and Memory two subsystems have their own hierarchical systems, and the association is obtained through Task Group.

CGroup Features

1. In Cgroups, a task is a process of the system.

2. Control group. Control groups are a set of processes that are divided according to a certain standard. The resource control in Cgroups is implemented in the control group. A process can be added to a control group and migrated from one process team to another. A process group's process can use cgroups to control the allocation of resources by the population, while being subject to the cgroups to control the population-set limits.

3. Level (hierarchy). Control groups can be organized into hierarchical forms, both of which control ethnic trees. Control the child nodes of the population tree The group is the child of the parent control group, inheriting the specific attributes of the parent control group.

4. Subsystem (SUBSYTEM). A subsystem is a resource controller, such as a CPU subsystem is a controller that controls CPU time allocation. Subsystems must be attached (attach) to one level to function, and when a subsystem is attached to a hierarchy, all control groups at that level are controlled by this subsystem.

CGroup Application Architecture

Figure 2. CGroup Typical Application Architecture diagram

As shown in 2, CGroup technology can be used to limit physical resources at the bottom of the operating system and play a Container role. Each JVM process in the diagram corresponds to a Container Cgroup level, which, through the various subsystems provided by Cgroup, can physically limit the thread level corresponding to each JVM process, including CPU, memory, and many other kinds of resources. The next section will demonstrate the CPU resource isolation of the application specifically.

Back to top of page

CGroup Deployment and application examples

Before explaining the principles of CGroup design, let's start with a simple experiment. The experiment was based on the Linux Centosv6.564 bit version, JDK1.7. The goal is to run a CPU-intensive Java program that, if not CGroup physically isolate the CPU cores, will automatically pick up the CPU cores from the OS hierarchy to run the program. Because the operating system level uses the time slice poll method randomly selects the CPU core as the running container, therefore will execute randomly on the 24 CPU cores on this machine. If we use CGroup for physical isolation, we can select some CPU cores as a specified operating carrier.

Listing 1.Java Program code

Open 4 User threads, where 1 threads are heavily CPU intensive, while the other 3 threads are idle public class Holdcpumain {public static class Holdcputask implements Runn able{@Overridepublic void Run () {//TODO auto-generated method Stubwhile (True) {Double A = Math.random () *math.random ();// Occupy CPUSystem.out.println (a);}}  }  public static class Lazytask implements runnable{@Overridepublic void Run () {//TODO auto-generated method Stubwhile (True) {try {thread.sleep;} catch (Interruptedexception e) {//TODO auto-generated catch Blocke.printstacktrace ();} Idle thread}}  } public   static void Main (string[] args) {for (int i=0;i<10;i++) {new Thread (new Holdcputask ()). Start (); } }}

Listing 1 starts 10 threads, all of which are doing CPU-intensive calculations that may run on 1 CPU cores or run on multiple cores, as determined by the operating system. We'll run the Listing 1 program in the background later on the Linux machine with commands. This experiment requires CPU resources to be limited, so we create our own hierarchy of "Zhoumingyao" on the Cpu_and_set subsystem.

Listing 2. Create a hierarchy

[[email protected] cpu_and_set]# ls-rlt total dosage 0-rw-r--r--1 root root 0 March 17:21 release_agent-rw-r--r--1 root Roo T 0 March 17:21 notify_on_release-r--r--r--1 root root 0 March 17:21 cpu.stat-rw-r--r--1 root root 0 March 17:21 CPU. shares-rw-r--r--1 root root 0 March 17:21 cpuset.sched_relax_domain_level-rw-r--r--1 root root 0 March 17:21 Cpuset.sc hed_load_balance-rw-r--r--1 root root 0 March 17:21 cpuset.mems-rw-r--r--1 root root 0 March 17:21 Cpuset.memory_sprea d_slab-rw-r--r--1 root root 0 March 17:21 cpuset.memory_spread_page-rw-r--r--1 root root 0 March 17:21 cpuset.memory_p ressure_enabled-r--r--r--1 root root 0 March 17:21 cpuset.memory_pressure-rw-r--r--1 root root 0 March 17:21 cpuset.me mory_migrate-rw-r--r--1 root root 0 March 17:21 cpuset.mem_hardwall-rw-r--r--1 root root 0 March 17:21 cpuset.mem_excl  usive-rw-r--r--1 root root 0 March 17:21 cpuset.cpus-rw-r--r--1 root root 0 March 17:21 cpuset.cpu_exclusive-rw-r--r-- 1 root root 0 March 21 17: cpu.rt_runtime_us-rw-r--r--1 root root 0 March 17:21 cpu.rt_period_us-rw-r--r--1 root root 0 March 17:21 cpu.cfs_q  uota_us-rw-r--r--1 root root 0 March 17:21 cpu.cfs_period_us-r--r--r--1 root root 0 March 17:21 cgroup.procsdrwxr-xr-x 2 root root 0 March 17:22 testdrwxr-xr-x 2 root root 0 March 16:36 test1-rw-r--r--1 root root 0 March 19:23 tasksdrwx  R-xr-x 2 root root 0 March 19:32 singledrwxr-xr-x 2 root root 0 March 19:59 single1drwxr-xr-x 2 root root 0 March 31 19:59 Single2drwxr-xr-x 2 root root 0 March 19:59 single3drwxr-xr-x 3 root root 0 April 3 17:34 aaaa[[email protected] Cpu_ and_set]# mkdir zhoumingyao[[email protected] cpu_and_set]# CD zhoumingyao[[email protected] zhoumingyao]#  LS-RLT total dosage 0-rw-r--r--1 root root 0 April 14:03 tasks-rw-r--r--1 root root 0 April 14:03 notify_on_release-r--r--r--1 Root root 0 April 14:03 cpu.stat-rw-r--r--1 root root 0 April 14:03 cpu.shares-rw-r--r--1 root root 0 April 14:03 CP Uset.sched_relax_domain_level-rw-r--r--1 root root 0 April 14:03 cpuset.sched_load_balance-rw-r--r--1 root root 0 April 14:03 cpuset.mems-rw-r--r-- 1 root root 0 April 14:03 cpuset.memory_spread_slab-rw-r--r--1 root root 0 April 14:03 cpuset.memory_spread_page-r--r- -r--1 root root 0 April 14:03 cpuset.memory_pressure-rw-r--r--1 root root 0 April 14:03 cpuset.memory_migrate-rw-r--r- -1 root root 0 April 14:03 cpuset.mem_hardwall-rw-r--r--1 root root 0 April 14:03 cpuset.mem_exclusive-rw-r--r--1 roo  T root 0 April 14:03 cpuset.cpus-rw-r--r--1 root root 0 April 14:03 cpuset.cpu_exclusive-rw-r--r--1 root root 0 April 30 14:03 cpu.rt_runtime_us-rw-r--r--1 root root 0 April 14:03 cpu.rt_period_us-rw-r--r--1 root root 0 April 14:03 cpu.cf s_quota_us-rw-r--r--1 root root 0 April 14:03 cpu.cfs_period_us-r--r--r--1 root root 0 April 14:03 Cgroup.procs

With the mkdir command to create a new folder Zhoumingyao, because the Cpu_and_set subsystem has been pre-loaded successfully, when the folder is created, the corresponding folder of the Cpu_and_set subsystem is created automatically.

Before running the Java program, we need to confirm the directory where the Cpu_and_set subsystem is installed, as shown in Listing 3.

Listing 3. Confirm Directory

[Email protected] zhoumingyao]# Lscgroup Cpuacct:/devices:/freezer:/net_cls:/blkio:/memory:/memory:/test2cpuset, Cpu:/cpuset,cpu:/zhoumingyaocpuset,cpu:/aaaacpuset,cpu:/aaaa/bbbbcpuset,cpu:/single3cpuset,cpu:/single2cpuset, Cpu:/single1cpuset,cpu:/singlecpuset,cpu:/test1cpuset,cpu:/test

The output shows that the CPUSET_CPU directory is Cpuset,cpu:/zhoumingyao, because the Java program used in this experiment is a multithreaded program, it is necessary to use the Cgexec command to help start, and not as some material on the network described, using Java–jar After the command is started, the PID process number is populated with the tasks file in the wrong way. Listing 4 Starts the Java program with the Cgexec command and requires the CPUSET_CPU directory address to be located in Listing 3.

Listing 4. Running Java Programs

[Email protected] zhoumingyao]# cgexec-g Cpuset,cpu:/zhoumingyao Java-jar test.jars

We set in the Cpuset.cpus file need to limit only 0-10 of these 11 CPU cores can be used to run the Java multithreaded applet that is launched in Listing 4 above. Of course CGroup can also limit the percentage of use per core, and there are no more descriptions, please read the CGroup official material by yourself.

List 5.CPU kernel limits

[email protected] zhoumingyao]# cat cpuset.cpus0-10

Next, use the TOP command to get all the associated thread IDs for the Java program started in Listing 4, and write these IDs to the Tasks file.

Listing 6. Set Thread ID

[email protected] zhoumingyao]# cat tasks26562657265826592660266126622663266426652666266726682669267026712672267326742675267626772678267926802681268226832684 268526862687268826892714271527162718

After all set up, we can check the operation of each CPU core through the top command, found that only 0-10 of these 11 CPU cores have compute resources called, can further confirm through the top command all the Java multithreaded threads that are launched in Listing 4.

Listing 7. Run results

Top-14:43:24 up to 6 days, Min. Users, load average:0.47, 0.40, 0.33tasks:715 Total, 1 running, 714 sleeping, 0 sto pped, 0 zombiecpu0:0.7%us, 0.3%sy, 0.0%ni, 99.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%stcpu1:1.0%us, 0.7%sy, 0.0%ni, 98.3%id , 0.0%wa, 0.0%hi, 0.0%si, 0.0%stcpu2:0.3%us, 0.3%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%stcpu3:1.0%us, 1.6%s Y, 0.0%ni, 97.5%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%stcpu4:0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%stCp U5:1.3%us, 1.9%sy, 0.0%ni, 96.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%stcpu6:3.8%us, 5.4%sy, 0.0%ni, 90.8%id, 0.0%wa, 0.0%hi , 0.0%si, 0.0%stcpu7:7.7%us, 9.9%sy, 0.0%ni, 82.4%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%stcpu8:4.8%us, 6.1%sy, 0.0%ni, 89.1% ID, 0.0%wa, 0.0%hi, 0.0%si, 0.0%stcpu9:0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%stcpu10:0.0%us, 0. 0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%stcpu11:0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0% Stcpu12:0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%stcpu13:0.0%us, 0.0%sy, 0.0%ni, 72.8%id, 0.0%wa, 0.0%hi, 4.3%si, 0.0%stCp U14:0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%stcpu15:0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0% Hi, 0.0%si, 0.0%stcpu16:0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%stcpu17:0.0%us, 0.0%sy, 0.0%ni,10 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%stcpu18:0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%stcpu19:0.0%u  S, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%stcpu20:0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%stcpu21:0.3%us, 0.3%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%stcpu22:0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0 %wa, 0.0%hi, 0.0%si, 0.0%stcpu23:0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%stmem:32829064k total, 56 95012k used, 27134052k free, 533516k buffersswap:24777720k total, 0k used, 24777720k free, 3326940k cached

Generally speaking, the use of CGroup is relatively simple, the main problem is that the network has a lack of detailed configuration of Chinese materials, once the reader through repeated experiments, master the configuration method, the use should not have a big problem.

Back to top of page

Analysis of design principle of Cgroup

CGroups source code is more clear, we can from the perspective of the process to analyze the relationship between CGroups related data structures. In Linux, the data structure of the management process is task_struct, where the code associated with Cgroups is shown in Listing 8:

Listing 8.task_struct Code

#ifdef config_cgroups/* Control Group Info protected by Css_set_lock */struct css_set *cgroups; /* Cg_list protected by Css_set_lock and Tsk->alloc_lock */struct list_head cg_list; #endif

Where the cgroups pointer points to a CSS_SET structure, and Css_set stores the cgroups information about the process. Cg_list is an embedded list_head structure that organizes the processes connected to the same css_set into a single linked list. Let's look at the structure of Css_set, as shown in Listing 9:

Listing 9.css_set Code

struct Css_set {atomic_t refcount;struct hlist_node hlist; struct list_head tasks; struct list_head cg_links; struct Cgro Up_subsys_state *subsys[cgroup_subsys_count]; struct Rcu_head rcu_head; };

Where RefCount is the reference number of the Css_set, because a css_set can be shared by multiple processes, as long as the cgroups information for those processes is the same, for example, in the same cgroup process at all created levels. Hlist is an embedded hlist_node that organizes all css_set into a hash table so that the kernel can quickly find specific css_set. Tasks points to all linked lists that are connected to this css_set process. Cg_links points to a linked list that is connected by Struct_cg_cgroup_link.

Subsys is a pointer array that stores a set of pointers to Cgroup_subsys_state. A cgroup_subsys_state is the information that the process is related to a particular subsystem. With this array of pointers, the process can obtain the corresponding Cgroups control information. The cgroup_subsys_state structure is shown in Listing 10:

Listing 10.cgroup_subsys_state Code

struct Cgroup_subsys_state {struct cgroup *cgroup; atomic_t refcnt; unsigned long flags; struct css_id *id;};

The Cgroup pointer points to a CGROUP structure, the cgroup that the process belongs to. Processes are controlled by subsystems and are actually implemented by adding to specific cgroup, because the cgroup is at a specific level, and the subsystem is echoed to the above. Through the above three structures, the process can be connected with the Cgroup: Task_struct->css_set->cgroup_subsys_state->cgroup. The Cgroup structure is shown in Listing 11:

Listing 11.cgroup Code

struct Cgroup {unsigned long flags; atomic_t count; struct list_head sibling; struct list_head children; struct Cgroup *p arent; struct Dentry *dentry; struct Cgroup_subsys_state *subsys[cgroup_subsys_count]; struct Cgroupfs_root *root;struct cgroup *top_cgroup; struct List_head css_sets; struct List_head release_list; struct List_head pidlists;struct Mutex Pidlist_mutex; struct Rcu_head rcu_head; struct List_head event_list; spinlock_t Event_list_lock; };

The Sibling,children and parent three embedded list_head are responsible for connecting the cgroup of the unified hierarchy into a cgroup tree.

Subsys is a pointer array that stores a set of pointers to Cgroup_subsys_state. This set of pointers points to the information associated with each subsystem in this cgroup, which is the same as in Css_set.

Root points to a cgroupfs_root structure, which is the corresponding structure of the Cgroup hierarchy. In this way, a few of the cgroups concepts mentioned earlier are all linked.

Top_cgroup points to the root cgroup of the hierarchy, which is the cgroup created automatically when the hierarchy is created.

Css_set points to a linked list of Struct_cg_cgroup_link, as in Css_set cg_links.

The following is an analysis of the relationship between a css_set and cgroup, and the structure of Cg_cgroup_link is shown in Listing 12:

Listing 12.cg_cgroup_link Code

struct Cg_cgroup_link {struct list_head cgrp_link_list; struct cgroup *cgrp; struct list_head cg_link_list; struct CSS_SE T *CG; };

Cgrp_link_list is connected to the linked list pointed to by Cgrouo->css_set, and cgrp points to this cg_cgroup_link-related cgroup.

Cg_link_list is connected to the linked list that css_set->cg_lonks points to, and CG points to this cg_cgroup_link-related css_set.

Cgroup and Css_set are a many-to-many relationship, and an intermediate structure must be added to connect the two, and that is the role of Cg_cgroup_link. CGRP and CG in Cg_cgroup_link are the joint primary keys of this structure, while cgrp_link_list and cg_link_list are connected to Cgroup and css_set corresponding linked lists, allowing the Cgroup or css_set to be can traverse the query.

So why Cgroup and Css_set are many-to-many relationships?

A process corresponds to a css_set, a css_set stores a set of processes (which may be shared by multiple processes, so it is a set of) information related to each subsystem, but this information may not be obtained from a cgroup, because a process can belong to several cgroup at the same time, As long as these cgroup are not at the same level. For example: We create a hierarchy A,a with CPU and memory two subsystems, process B belongs to the root of a cgroup; then we create a hierarchy c,c with NS and Blkio two subsystems attached, and process B is also the root of C Cgrou p; then the CPU and memory information for process B is obtained from the root cgroup of a, and the NS and Blkio information is obtained from the root of C Cgroup. Therefore, a css_set stored cgroup_subsys_state can correspond to multiple cgroup. On the other hand, Cgroup also stores a set of Cgroup_subsys_state, a group of cgroup_subsys_state that are cgroup from subsystems attached to the hierarchy. There can be multiple processes in a cgroup, and the css_set of those processes are not necessarily the same, because some processes may also join other cgroup. However, the cgroup_subsys_state associated with the Cgroup in the same Cgroup is managed by the Cgroup (the process Control in Cgroups is in Cgroup), so a cgroup can also correspond to multiple CSS _set.

From the previous analysis, we can see that it is easy to locate from task to Cgroup, but all the tasks that get this cgroup from Cgroup must pass through this structure. Each process points back to a css_set, and all processes associated with the Css_set are linked to the css_set->tasks linked list, and cgroup through an intermediate structure cg_cgroup_link to find all css_set associated with it So that all processes associated with the Cgroup can be obtained. Finally, let's look at the structure of the hierarchy and subsystem. The hierarchy corresponding to the structure is cgroupfs_root as shown in Listing 13:

Listing 13.cgroupfs_root Code

struct Cgroupfs_root {struct super_block *sb; unsigned long subsys_bits; int hierarchy_id;unsigned long actual_subsys_bit S struct List_head subsys_list; struct Cgroup top_cgroup; int number_of_cgroups; struct List_head root_list; unsigned long flags; Char Release_agent_path[path_max]; Char Name[max_cgroup_root_namelen]; };

SB points to the file system data block associated with this level. Subsys_bits and Actual_subsys_bits point to the subsystems that will be attached to the hierarchy and the subsystems that are now actually attached to the hierarchy, which are used when the subsystem is attached to the hierarchy. HIERARCHY_ID is the unique ID for this level. Top_cgroup points to the root cgroup of the hierarchy. Number_of_cgroups records the number of cgroup at that level. Root_list is an embedded list_head that connects all the hierarchy of the system into a linked list. The structure of the subsystem is Cgroup_subsys, and the code is shown in Listing 14.

Listing 14. Cgroup_subsys Code

struct Cgroup_subsys {struct cgroup_subsys_state * (*create) (struct Cgroup_subsys *ss, struct cgroup *cgrp); Int (*pre_des Troy) (struct Cgroup_subsys *ss, struct cgroup *cgrp); void (*destroy) (struct Cgroup_subsys *ss, struct cgroup *cgrp); Int (*can_attach) (struct Cgroup_subsys *ss, struct cgroup *cgrp, struct task_struct *tsk, bool threadgroup); void (*cancel_attach) (struct Cgroup_subsys *ss, struct cgroup *cgrp, struct task_struct *tsk, bool threadgroup); void (*attach) (struct Cgroup_subsys *ss, struct cgroup *cgrp, struct cgroup *old_cgrp, struct task_struct *tsk, bool Threa Dgroup); void (*fork) (struct Cgroup_subsys *ss, struct task_struct *task); void (*exit) (struct Cgroup_subsys *ss, struct task_struct *task); Int (*populate) (struct Cgroup_subsys *ss, struct cgroup *cgrp); void (*post_clone) (struct Cgroup_subsys *ss, struct cgroup *cgrp); void (*bind) (struct Cgroup_subsys *ss, struct cgroup *root); int subsys_id; int active; int disabled; int early_init; BOOL use_id; #define MAX_CGRoup_type_namelen-const char *name; struct Mutex Hierarchy_mutex; struct Lock_class_key subsys_key; struct Cgroupfs_root *root; struct List_head sibling; struct IDR IDR; spinlock_t Id_lock; struct module *module; };

Cgroup_subsys defines a set of operations that allow each subsystem to be implemented according to its own needs. This is equivalent to the abstract base class in C + +, and then each specific subsystem corresponding to Cgroup_subsys is the subclass that implements the corresponding operation. Similar ideas are used in cgroup_subsys_state, Cgroup_subsys_state does not define control information, but only defines the common information required by each subsystem, such as the cgroup_subsys_state dependent Cgroup. The subsystems then define their own process control information structure according to their own needs, and finally include the cgroup_subsys_state in their respective structures, so that macros such as the container_of of the Linux kernel can be Cgroup_subsys _state to obtain the corresponding structure.

From the basic level order definition, it is composed of task_struct, Css_set, Cgroup_subsys_state, Cgroup, Cg_cgroup_link, Cgroupfs_root, Cgroup_subsys and other structures. CGroup can be essentially a response relationship from a process-level response. Subsequent articles will be further analyzed for file systems and subsystems.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

CGroup Introduction, application examples and principle description (published in the IBM Developer Forum)