Cgroup Learning (2) -- cgroup Framework Structure

Cgroup Framework Structure

In this chapter, we will first introduce the Framework Structure of a cgroup and the corresponding file definitions of the cgroup file system. Here, let's take a look at the main structural relationships of cgroup:

 

Figure 2 main data structure relationships

This figure contains all the major data structures of the cgroup and their relationships. Cgroupfs_root is equivalent to the Dir specified by the Mount operation. cgroup indicates the mkdir cg_test in the Mount directory. cgroup_subsys indicates the base class (-O option) of all subsys ), it defines the corresponding methods and attributes of all subsys; cgroup_subsys_state is the abstract class of the group control body of subsys managed by cgroup (this name is a bit awkward and may be understood later ), each subsystem has its own implementation class, such as cpuset, task_group, and mem_cgroup, that is, cgroup_subsys_state implements C language polymorphism. cgroup only manages the cgroup_subsys_state structure, and different subsystems follow this structure, container_of is used to restore the real control body. cg_cgroup_link defines the many-to-many relationship between cgroup and css_set (why does one css_set have multiple cgroups? -- The root cause is that a task will be attach to multiple hierarchy, and a cgroup under each hierarchy will manage the task (one task has only one css_set ), so there are several hierarchy, and the css_set has several cgroups. Why does one cgroup have multiple css_sets? -- A cgroup can attach multiple processes, and their css_set may be different. This is determined by the cgroups to which the task belongs. Only the cgroups to which the task belongs is the same, they will share a css_set. Otherwise, their css_set will be different ), css_set-> cg_links points to all cgroups that manage the css_set (these cgroups are linked by cg_cgroup_link-> cg_link_list cg_cgroup_link ), similarly, cgroup-> css_sets point to all css_sets managed by the cgroup (these css_sets are linked by cg_cgroup_link-> cgrp_link_list cg_cgroup_link ), the reason for adding such an intermediate structure is mainly to remove the coupling relationship between css_set and cgroup (if we want to delete the cgroup operation when the two are directly connected, and added this structure Action ?). All css_sets are stored in the global hash table of css_set_table. Their hash functions and keys are css_set_hash (css_set-> subsys). css_set establishes a one-to-multiple relationship between tasks and them, different processes may point to the same css_set (for example, the parent-child process of fork), while css_set-> tasks is the head of all the tasks lists that reference the css_set, tasks are linked using task-> cg_list. Similarly, all cgroup_subsys of a cgroupfs_root-> subsys_list are organized by cgroupfs_root-> and all cgroupfs_root are connected to the global variable header of roots through its root_list.
Through this figure, we can know that the list of tasks is not saved in the cgroup. So how do we obtain all the tasks when we view the tasks file (cat tasks? -- Cgroup-> css_sets stores all the css_sets it manages (connected through cg_cgroup_link), and css_set-> tasks stores all tasks that reference it (this process corresponds to cgroup_tasks_open ); similarly, when we CAT/proc/cgroup, we can see which cgroups are managed by a task. This process is obtained through task-> cgroups to obtain its css_set, then obtain the cgroup to which it belongs from css_set-> cg_links (connected through cg_cgroup_link) (this process corresponds to cgroup_open-> proc_cgroup_show-> task_cgroup_from_root. The actual code process is a little different from the analysis, because the output requirements are differentiated by root, but the relationship is the same ).
Note: A top cgroup is generated after the mount, that is, it is both cgroupfs_root and cgroup.