cgroup使用举例和linux内核源码详解

     cgroup的原理其实并不复杂，用法也比较简单。但是涉及的内核数据结构真的复杂，错综复杂的数据结构感觉才是cgroup真正的难点。本文结合个人学习cgroup源码的心得，尽可能以举例的形式，总结cgroup整体框架和核心源码实现，尽可能少贴源码。本次是在centos 7.6测试的cgroup，源码注释基于3.10.96。更详细的源码注释见https://github.com/dongzhiyan-stack/kernel-code-comment。

这里先把cgroup涉及的各个数据结构的关系图发下，后边需要多次用到这幅图。(高清大图查看方法：鼠标右键点击图片后，点击"在新标签页中打开图片"，然后在新窗口点击图片即可查看高清大图)

1 cgroup的创建

centos 7.6系统启动后，默认systemd就已经挂载好了cgroup文件系统

[root@localhost ~]# mount | grep cgroup
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,seclabel,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,hugetlb)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,cpuacct,cpu)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,perf_event)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,pids)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,cpuset)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,net_prio,net_cls)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,memory)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,freezer)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,devices)

进入cgroup挂载目录看一下cgroup各个子系统，如下：

[root@localhost ~]# cd /sys/fs/cgroup/
[root@localhost cgroup]# ls
blkio  cpu  cpuacct  cpu,cpuacct  cpuset  devices  freezer  hugetlb  memory  net_cls  net_cls,net_prio  net_prio  perf_event  pids  systemd

    cpu、blkio、memory是比较常见的cgroup子系统，分别用来限制进程CPU使用率、IO传输吞吐量IOPS、内存分配。每个cgroup子系统都有特定的功能，这个比较好理解。这里需要提一下另一个概念：cgroup层级，如下是从Linux资源管理之cgroups简介 - 美团技术团队 直接贴过来的演示cgroup层级的示意图：

    个人认为一个cgroup层级更像是一个包含不同功能的cgroup子系统集合。比如示意图的cgroup层级A集成了cpu、cpuacct两个cgroup子系统，cgroup层级B集成了memory这个cgroup子系统。上边介绍centos 7.6的cgroup子系统时，ls  /sys/fs/cgroup时看到了很多个cgroup子系统，这种情况应该只有一个cgroup层级，当然你也可以再创建一个cgroup层级。网上关于cgroup层级的介绍有点抽象，当然我的理解也不一定到位。

回到cgroup子系统，如果我们想限制进程1的CPU使用率不能超过50%，可以执行如下命令：

[root@localhost cgroup]# cd /sys/fs/cgroup/cpu
[root@localhost cpu]# mkdir test
[root@localhost cpu]# cd test
[root@localhost test]# ls
cgroup.clone_children  cgroup.procs  cpuacct.usage         cpu.cfs_period_us  cpu.rt_period_us   cpu.shares  notify_on_release
cgroup.event_control   cpuacct.stat  cpuacct.usage_percpu  cpu.cfs_quota_us   cpu.rt_runtime_us  cpu.stat    tasks
[root@localhost test]# cat cpu.cfs_quota_us
-1
[root@localhost test]# cat cpu.cfs_period_us
100000
[root@localhost test]# echo 50000 > cpu.cfs_quota_us
[root@localhost test]# echo 进程1PID > tasks

之后top进程1的CPU使用率最大50%，即便进程1是陷入while(1);死循环。我们赋予cpu.cfs_quota_us的是50000，cpu.cfs_period_us是100000。cpu.cfs_period_us表示一个调度周期，cpu.cfs_quota_us表示一个调度周期进程可以使用的最大配额，显然是一半，即50%。关于cgroup的使用，这里不再介绍，我们重点介绍以上这些命令设置的cgroup内核源码实现。

首先” mkdir test”命令，内核流程是sys_mkdir-> SyS_mkdirat-> vfs_mkdir-> cgroup_mkdir-> cgroup_create

1. static long cgroup_create(struct cgroup *parent, struct dentry *dentry,//dentry是新创建的目录的dentry
2.                  umode_t mode)
3. {
4.     struct cgroup *cgrp;
5.     struct cgroupfs_root *root = parent->root;
6.     //分配本次的cgroup结构体，一个目录对应一个struct cgroup
7.     cgrp = kzalloc(sizeof(*cgrp), GFP_KERNEL);
8.     //指向本cgroup对应目录的dentry
9.     cgrp->dentry = dentry;
10.     //cgroup的parent
11.     cgrp->parent = parent;
12.     //指向根cgroupfs_root
13.     cgrp->root = parent->root;
14.     //遍历cgroupfs_root->subsys_list链表，找到该链表上的cgroup_subsys，即cgroup子系统，然后执行该cgroup子系统的css_alloc()函数
15.     for_each_subsys(root, ss) {
16.         //分配cgroup子系统的控制结构(如cpu的是task_group)，返回task_group结构的第一个成员struct cgroup_subsys_state css的地址赋于css
17.         css = ss->css_alloc(cgrp);//cpu子系统是cpu_cgroup_css_alloc()
18.         //初始化struct cgroup_subsys_state css，并赋值cgrp->subsys[ss->subsys_id]=css
19.         init_cgroup_css(css, ss, cgrp);
20.     }
21.     //创建该目录的inode，建立dentry和inode的关系
22.     err = cgroup_create_file(dentry, S_IFDIR | mode, sb);
23.     //生成该cgroup目录下相关子系统的控制文件，如"tasks"、"notify_on_release"等
24.     err = cgroup_populate_dir(cgrp, true, root->subsys_mask);
25. }

   这个函数一下引出了很多数据结构，struct cgroup、struct cgroupfs_root、struct cgroup_subsys、struct cgroup_subsys_state。

1  struct  cgroup:当我们mkdir  test创建一个cgroup目录时，首先会在vfs层创建一个该目录的dentry结构，然后执行cgroup文件系统的cgroup_mkdir()->cgroup_create()函数，该函数首先分配一个struct cgroup结构。每创建一个cgroup目录，都要分配一个struct cgroup结构与之对应。

2   struct cgroupfs_root和struct cgroup_subsys：当cgroup文件系统mount挂载时(比如cpu cgroup挂载时执行的mount -t cgroup -ocpu cpu /sys/fs/cgroup/cpu,cpuacct命令)，内核里最后执行cgroup_mount()，分配struct cgroupfs_root和super_block结构，二者一一对应。然后执行cgroup_mount()->rebind_subsystems()中，按照该cgroup子系统编号从subsys[i]全局数组取出struct cgroup_subsys结构(cpu cgroup子系统的是struct cgroup_subsys  cpuset_subsys，blkio的是struct cgroup_subsys blkio_subsys)，然后把struct cgroup_subsys移动到struct cgroupfs_root的subsys_list链表。

3  struct cgroup_subsys_state：以cpu 子系统为例，其他cgroup子系统类似。每次创建cgroup目录分配struct  cgroup后，都会执行cpu_cgroup_css_alloc()分配cgroup控制结构struct task_group，而struct task_group的第一个成员就是struct cgroup_subsys_state。再令struct  cgroup结构的成员struct cgroup_subsys_state *subsys[cpu子系统ID]指向刚才分配的struct cgroup_subsys_state结构。后续container_of(cgroup_subsys_state指针)就指向刚才分配的struct task_group。如此就可以通过struct  cgroup找到对应的struct  task_group，这是cgroup_subsys_state存在的意义，牵线搭桥。

struct group代表的是cgroup目录，struct  task_group代表的是该cgroup目录对应的cpu cgroup子系统的控制结构，还有struct  task_group的第一个成员struct cgroup_subsys_state   css，3者 一一对应。将来正是用struct  task_group限制进程的CPU使用率。

为了便于理解，把这些数据结构的关系图单独截个大图，关系标的还算明确。(高清大图查看方法：鼠标右键点击图片后，点击"在新标签页中打开图片"，然后在新窗口点击图片即可查看高清大图)

     cpu、memory、blkio等cgroup子系统用struct cgroup_subsys表示，struct cgroupfs_root是该cgroup子系统mount挂载时分配的，与super_block一一对应。所以cgroup子系统cgroup_subsys和它的cgroupfs_root一一对应，可以看些示意图。

     结合这个示意图，再啰嗦一下彼此的关系。struct  cgroup的成员struct  cgroup_subsys_state *subsys[]保存的是struct  cgroup_subsys_state指针。比如，当该cgroup是属于cpu cgroup子系统，subsys[cpuset_subsys_id]   ( cpuset_subsys_id是cpu cgroup子系统ID，这个数组只有一个成员指向的cgroup_subsys_state指针有效)指向的cgroup_subsys_state是struct  task_group结构的成员struct  cgroup_subsys_state css。这样知道了cgroup_subsys_state的地址，container_of(cgroup_subsys_state)就是struct  task_group的地址。

如下是常见的cpu、memory、blkio这3个cgroup子系统的struct cgroup_subsys结构。

1. struct cgroup_subsys cpu_cgroup_subsys = {
2.     .name       = "cpu",
3.     .css_alloc  = cpu_cgroup_css_alloc,//创建cpu cgroup具体的控制单元task_group
4.     .css_free   = cpu_cgroup_css_free,
5.     .css_online = cpu_cgroup_css_online,
6.     .css_offline    = cpu_cgroup_css_offline,
7.     .can_attach = cpu_cgroup_can_attach,
8.     .attach     = cpu_cgroup_attach,
9.     .exit       = cpu_cgroup_exit,
10.     .subsys_id  = cpu_cgroup_subsys_id,//cpu cgroup子系统的id是cpu_cgroup_subsys_id
11.     .base_cftypes   = cpu_files, //cpu cgroup子系统独有的控制文件
12.     .early_init = 1,
13. }
14. struct cgroup_subsys mem_cgroup_subsys = {
15.     .name = "memory",
16.     .subsys_id = mem_cgroup_subsys_id,
17.     .css_alloc = mem_cgroup_css_alloc,
18.     .css_online = mem_cgroup_css_online,
19.     .css_offline = mem_cgroup_css_offline,
20.     .css_free = mem_cgroup_css_free,
21.     .can_attach = mem_cgroup_can_attach,
22.     .cancel_attach = mem_cgroup_cancel_attach,
23.     .attach = mem_cgroup_move_task,
24.     .bind = mem_cgroup_bind,
25.     .base_cftypes = mem_cgroup_files,//memory cgroup子系统独有的控制文件
26.     .early_init = 0,
27.     .use_id = 1,
28. };
29. struct cgroup_subsys blkio_subsys = {
30.     .name = "blkio",
31.     .css_alloc = blkcg_css_alloc,
32.     .css_offline = blkcg_css_offline,
33.     .css_free = blkcg_css_free,
34.     .can_attach = blkcg_can_attach,
35.     .subsys_id = blkio_subsys_id,
36.     .base_cftypes = blkcg_files,
37.     .module = THIS_MODULE,
38.     .broken_hierarchy = true,
39. };

每个cgroup子系统的struct cgroup_subsys结构最终是保存在struct cgroup_subsys *subsys[CGROUP_SUBSYS_COUNT]全局结构体指针数组中，如下:

#define SUBSYS(_x) [_x ## _subsys_id] = &_x ## _subsys,

1. static struct cgroup_subsys *subsys[CGROUP_SUBSYS_COUNT] = {
2. #include
3. SUBSYS(cpuset)
4. SUBSYS(debug)
5. SUBSYS(cpu_cgroup)//限制CPU
6. SUBSYS(cpuacct)
7. SUBSYS(mem_cgroup)//限制mem
8. SUBSYS(devices)
9. SUBSYS(freezer)
10. SUBSYS(net_cls)
11. SUBSYS(blkio)//限制block
12. SUBSYS(net_prio)
13. SUBSYS(hugetlb)
14. };

把这些结构体拆开简化后如下：

1. static struct cgroup_subsys *subsys[CGROUP_SUBSYS_COUNT] = {
2. ………
3. [cpuset_subsys_id] = cpu_cgroup_subsys,
4. ………
5. [mem_cgroup_subsys_id] = mem_cgroupt_subsys,
6. [blkio_subsys_id] = blkio_subsys,
7. ………
8. };

终于看到cpu、memory、blkio等cgroup子系统的struct cgroup_subsys结构cpu_cgroup_subsys、mem_cgroupt_subsys、blkio_subsys了。cpuset_subsys_id是cpu cgroup子系统的ID，其他类似。

回到cgroup_create()函数，该函数最后执行cgroup_populate_dir()创建该cgroup目录下相关子系统的控制文件。什么意思？前文执行mkdir test创建”test”这个cgroup目录后，ls test便会看到” tasks”、” cpu.cfs_period_us”、” cpu.cfs_quota_us”等文件。我们并没有在”test” cgroup目录下创建这些文件，从何而来？正是sys_mkdir-> SyS_mkdirat-> vfs_mkdir-> cgroup_mkdir-> cgroup_create-> cgroup_populate_dir()中创建的，下一节讲解。

2 cgruop目录下文件的创建与读写

2.1 cgruop目录下文件的创建

首先说明一下内核struct cftype表示一个cgroup文件。看下cgroup_populate_dir()函数的关键源码。

1. static int cgroup_populate_dir(struct cgroup *cgrp, bool base_files,
2.                    unsigned long subsys_mask)
3. {
4.     struct cgroup_subsys *ss;
5.     //从struct cftype files[]全局结构体获取cgroup基本的文件cftype，比如"task"、"release_agent"等基本cgroup文件，然后在cgroup子系统的目录下创建这些基本文件*/
6.     if (base_files) {
7.         err = cgroup_addrm_files(cgrp, NULL, files, true);
8.     }
9.    /*cgrp->root指向根cgroupfs_root，这是遍历根cgroupfs_root的subsys_list链表上的cpu、memory、blkio等cgroup_subsys,再通过cgroup_subsys的成员sibling container_of找到cftype_set，再找到cftype_set的成员cfts指向的cftype。这个cftype是每个cgroup_subsys特有的cftype。上边的是创建cgroup基本文件，这里的cftype是cpu、memory、blkio特有的cgroup文件。*/
10.     for_each_subsys(cgrp->root, ss) {
11.         struct cftype_set *set;
12.         /*这是限定只有与subsys_mask指定的cgroup子系统匹配才能执行下边的cgroup_addrm_files()创建特定cgroup子系统的cgroup文件。比如在cpu cgroup目录下创建cgroup文件，该if只有是ss是cpu的cgroup_subsys才不成立*/
13.         if (!test_bit(ss->subsys_id, &subsys_mask))
14.             continue;
15.        
16.         /*遍历cgroup_subsys该cgroup子系统cftsets链表上的cftype_set，再通过cftype_set的cfts找到cgroup子系统特有的struct cftype[]，创建cftype指定的该cgroup子系统特有的cgroup文件。cgroup子系统特有的struct cftype[]有哪些呢?如struct cftype cpu_files[]，struct cftype blkcg_files[]，struct cftype throtl_files[].更详细见struct cftype结构体描述。*/
17.         list_for_each_entry(set, &ss->cftsets, node)
18.             cgroup_addrm_files(cgrp, ss, set->cfts, true);
19.     }
20. }
22. static int cgroup_addrm_files(struct cgroup *cgrp, struct cgroup_subsys *subsys,
23.                   struct cftype cfts[], bool is_add)
24. {
25.     struct cftype *cft;
26.     //依次取出struct cftype files定义的文件
27.     for (cft = cfts; cft->name[0] != '\0'; cft++) {
28.         //cft指向struct cftype files[]定义的每个基本文件结构。以cft指向成员内容，创建cgroup下的文件，常见的"tasks"等等,
29.         cgroup_add_file(cgrp, subsys, cft);
30.     }
31. }
33. //以cft指向成员内容，创建cgroup下的文件，常见的"tasks"等等
34. static int cgroup_add_file(struct cgroup *cgrp, struct cgroup_subsys *subsys,
35.                struct cftype *cft)//创建cgroup基本文件时，cft指向struct cftype files[]定义的每个基本文件结构
36. {
37.     //cgroup子系统父目录的dentry，下边就是在这个dentry下创建cgroup子文件"tasks"等等
38.     struct dentry *dir = cgrp->dentry;
39.     struct cgroup *parent = __d_cgrp(dir);
40.     struct dentry *dentry;
41.     struct cfent *cfe;
42.    
43.     //文件名字，比如"tasks"
44.     strcat(name, cft->name);
45.     //分配cfe，cfe代表了一个cgroup目录下的的cgroup文件
46.     cfe = kzalloc(sizeof(*cfe), GFP_KERNEL);
47.     //在父目录base下，查找或者创建name指定的文件dentry
48.     dentry = lookup_one_len(name, dir, strlen(name));
49.     //cfe保存这个cgroup文件的基本信息
50.     cfe->type = (void *)cft;
51.     cfe->dentry = dentry;
52.     dentry->d_fsdata = cfe;
53.     //分配文件的inode，建立inode和dentry联系，成功返回0
54.     error = cgroup_create_file(dentry, mode | S_IFREG, cgrp->root->sb);
55.     //把新分配的cfe添加到cgroup父目录的struct cgroup的files链表
56.     list_add_tail(&cfe->node, &parent->files);
57. }

一下又冒出了几个结构体struct cftype、struct cfent。struct cftype包含原始的cgroup文件信息，它来自两部分。一部分是cgroup基本文件，如”tasks”、” notify_on_release”等等，cpu、blkio、memory等cgroup子系统都有。这些文件信息定义在kernel/cgroup.c文件的struct cftype files[]这个结构体数组，如下所示：

// cgroup子系统base控制文件结构struct cftype files[]

1. static struct cftype files[] = { //这个是 cgroup子系统的基本文件
2.     {
3.         .name = "tasks",
4.         .open = cgroup_tasks_open,
5.         .write_u64 = cgroup_tasks_write,//绑定每个进程
6.         .release = cgroup_pidlist_release,
7.         .mode = S_IRUGO | S_IWUSR,
8.     },
9.     {
10.         .name = CGROUP_FILE_GENERIC_PREFIX "procs",
11.         .open = cgroup_procs_open,
12.         .write_u64 = cgroup_procs_write,
13.         .release = cgroup_pidlist_release,
14.         .mode = S_IRUGO | S_IWUSR,
15.     },
16.     {
17.         .name = "notify_on_release",
18.         .read_u64 = cgroup_read_notify_on_release,
19.         .write_u64 = cgroup_write_notify_on_release,
20.     },
21.     .............
22. };

但是每个cgroup子系统也有特有的cgroup控制文件，如cpu 子系统的” cpu.cfs_period_us”、” cpu.cfs_quota_us”等cgroup文件，memory子系统的” memory.limit_in_bytes”、” memory.usage_in_bytes”等cgroup文件，blkio子系统的” blkio.throttle.read_iops_device”、” blkio.throttle.write_iops_device”等cgroup文件。我们看下cpu cgroup子系统特有的控制文件结构体，如下：

1. static struct cftype cpu_files[] = {
2.     {
3.         .name = "cfs_quota_us",//cfs进程运行时间配额
4.         .read_s64 = cpu_cfs_quota_read_s64,
5.         .write_s64 = cpu_cfs_quota_write_s64,
6.     },
7.     {
8.         .name = "cfs_period_us",//cfs进程运行周期
9.         .read_u64 = cpu_cfs_period_read_u64,
10.         .write_u64 = cpu_cfs_period_write_u64,
11.     },
12.     {
13.         .name = "stat",
14.         .read_map = cpu_stats_show,
15.     }
16. }

blkio cgroup子系统独有的控制文件结构体数组struct cftype throtl_files[]

1. static struct cftype throtl_files[] = {
2.     ..........
3.     {
4.         .name = "throttle.read_iops_device",
5.         .private = offsetof(struct throtl_grp, iops[READ]),
6.         .read_seq_string = tg_print_conf_uint,
7.         .write_string = tg_set_conf_uint,
8.         .max_write_len = 256,
9.     },
10.     {
11.         .name = "throttle.write_iops_device",
12.         .private = offsetof(struct throtl_grp, iops[WRITE]),
13.         .read_seq_string = tg_print_conf_uint,
14.         .write_string = tg_set_conf_uint,
15.         .max_write_len = 256,
16.     },
17.     ..........
18. }

memory cgroup子系统控制文件结构体数组struct cftype mem_cgroup_files []

1. static struct cftype mem_cgroup_files[] = {
2.     {
3.         .name = "usage_in_bytes",
4.         .private = MEMFILE_PRIVATE(_MEM, RES_USAGE),
5.         .read = mem_cgroup_read,
6.         .register_event = mem_cgroup_usage_register_event,
7.         .unregister_event = mem_cgroup_usage_unregister_event,
8.     },
9.     {
10.         .name = "max_usage_in_bytes",
11.         .private = MEMFILE_PRIVATE(_MEM, RES_MAX_USAGE),
12.         .trigger = mem_cgroup_reset,
13.         .read = mem_cgroup_read,
14.     },
15.     {
16.         .name = "limit_in_bytes",//设置进程内存使用
17.         .private = MEMFILE_PRIVATE(_MEM, RES_LIMIT),
18.         .write_string = mem_cgroup_write,
19.         .read = mem_cgroup_read,
20.     },
21.     .........
22. }

以上提到的这些cgroup文件结构体struct cftype是怎么添加到系统的呢？又是怎么被使用而最终在cgroup目录创建这些文件呢？我们一一道来：

struct cftype主要有3类

1  第一类，cgroup子系统基本的struct cftype数组，对应"tasks"、"release_agent"等cgroup文件，保存在struct cftype files[]全局结构体数组，这些cgroup文件的创建在cgroup_create->cgroup_populate_dir->cgroup_addrm_files(cgrp, NULL, files, true)( if (base_files)那个分支)，前文提过。

接着

2  第二类，每个cgroup子系统struct cgroup_subsys结构体base_cftypes成员指向的struct cftype结构体数组。如cpu cgroup子系统struct cgroup_subsys cpu_cgroup_subsys[]的struct cftype cpu_files[]，如下：

1. struct cgroup_subsys cpu_cgroup_subsys = {
2.     .name       = "cpu",
3.     .css_alloc  = cpu_cgroup_css_alloc,
4.     .css_free   = cpu_cgroup_css_free,
5.     .css_online = cpu_cgroup_css_online,
6.     .css_offline    = cpu_cgroup_css_offline,
7.     .can_attach = cpu_cgroup_can_attach,
8.     .attach     = cpu_cgroup_attach,
9.     .exit       = cpu_cgroup_exit,
10.     .subsys_id  = cpu_cgroup_subsys_id,
11.     .base_cftypes   = cpu_files,
12.     .early_init = 1,
13. };

cpu cgroup子系统struct cgroup_subsys的base_cftypes成员指向的struct cftype cpu_files[]是怎么添加到cgroup相关的数据结构呢？这是在cgroup子系统模块初始化cgroup_init->cgroup_init_subsys()->cgroup_init_cftsets，源码如下：

1. int __init cgroup_init(void)
2. {
3.     for (i = 0; i < CGROUP_SUBSYS_COUNT; i++) {
4.         //从subsys[]按照cgroup子系统编号依次取出 cpuset_subsys 、 blkio_subsys等这些cgroup子系统结构体struct cgroup_subsys
5.         struct cgroup_subsys *ss = subsys[i];
6.         cgroup_init_subsys(ss);//cpu、mem、cgroup等cgroup_subsys结构初始化赋值
7.     }
8. }
10. static void __init cgroup_init_subsys(struct cgroup_subsys *ss)
11. {
12.     cgroup_init_cftsets(ss);//初始化cpu、memcory、block 的cgroup文件
13.     list_add(&ss->sibling, &rootnode.subsys_list);//cgroup_subsys添加到subsys_list链表
14.     ss->root = &rootnode;//cgroup_subsys->root 指向rootnode
15.    
16.     css = ss->css_alloc(dummytop);//分配顶层cgroup的struct cgroup_subsys_state
17.     init_cgroup_css(css, ss, dummytop);//初始化顶层cgorup的struct cgroup_subsys_state
18. }
20. static void __init_or_module cgroup_init_cftsets(struct cgroup_subsys *ss)
21. {
22.     INIT_LIST_HEAD(&ss->cftsets);
23.     if (ss->base_cftypes) {
24.         //cgroup_subsys的cftype_set的cfts指向cgroup子系统cgroup_subsys的成员base_cftypes指向的struct cftype数组
25.         ss->base_cftset.cfts = ss->base_cftypes;
26.         //把cgroup子系统struct cgroup_subsys的成员base_cftypes指向的struct cftype数组添加到cgroup子系统struct cgroup_subsys的cftsets链表
27.         list_add_tail(&ss->base_cftset.node, &ss->cftsets);
28.     }
29. }

除了cpu的struct cftype cpu_files[]数组，memory子系统的struct cftype mem_cgroup_files[]数组，blkio子系统的struct cftype blkcg_files[]数组，都是以这种形式添加到各个cgroup子系统struct cgroup_subsys的cftsets链表。

这些cgroup文件的创建在：cgroup_create->cgroup_populate_dir->cgroup_addrm_files(cgrp, ss, set->cfts, true)( for_each_subsys(cgrp->root, ss)那个分支)

3  第三类，每个cgroup子系统动态添加的struct cftype数组。比如blkio  cgroup子系统blkcg_policy_register->cgroup_add_cftypes()，把block层流控的struct cftype throtl_files[]数组动态添加到blkio子系统struct cgroup_subsys的cftsets链表，源码如下：

int blkcg_policy_register(struct blkcg_policy *pol)

{

    //这个pol->cftypes就是blkio 流控的cftype数组struct cftype throtl_files[]

    if (pol->cftypes)//把blkio流控的cftype数组struct cftype throtl_files[]添加到blkio cgorup子系统struct blkio_subsys的cftsets链表

        WARN_ON(cgroup_add_cftypes(&blkio_subsys, pol->cftypes)

}

//把cgroup子系统特有的cgroup控制文件cftype数组添加到cgorup子系统struct cgroup_subsys的cftsets链表

1. int cgroup_add_cftypes(struct cgroup_subsys *ss, struct cftype *cfts)
2. {
3.     struct cftype_set *set;
5.     //分配cftype_set
6.     set = kzalloc(sizeof(*set), GFP_KERNEL);
7.     if (!set)
8.         return -ENOMEM;
10.     cgroup_cfts_prepare();
11.     //cftype_set的cfts指向cftype数组
12.     set->cfts = cfts;
13.     //cftype_set靠其node成员添加到cgroup_subsys的cftsets链表
14.     list_add_tail(&set->node, &ss->cftsets);
15.     cgroup_cfts_commit(ss, cfts, true);
17.     return 0;
18. }

    这些cgroup文件的创建也是在cgroup_create->cgroup_populate_dir->cgroup_addrm_files(cgrp, ss, set->cfts, true)(for_each_subsys(cgrp->root, ss)那个分支)。

    对于第2、3点，需要特别说明，cgroup_populate_dir()函数for_each_subsys(cgrp->root, ss)那个分支，是遍历该cgroup子系统struct cgroup_subsys的成员cftsets链表上的cftype_set，再通过cftype_set的成员cfts找到cgroup子系统特有的struct cftype[]结构体数组。然后根据这个数组创建指定的cgroup文件。这些cgroup子系统特有的控制文件cftype数组前文已经介绍过怎么添加到cgroup_subsys该cgroup子系统cftsets链表上。

    需要说明，struct cftype_set存在的意义就是为了把每个cgroup子系统特有的cgroup文件数组struct cftype[]添加到cgroup子系统struct cgroup_subsys的成员cftsets链表上。为什么要这样呢？因为每个cgroup子系统可能有多个特有的struct cftype[]数组，比如blkio cgroup子系统的struct cftype blkcg_files[]和 struct cftype throtl_files[]，每来一个struct cftype[]数组都添加到struct cgroup_subsys的成员cftsets链表上即可。struct cftype_set的成员struct cftype *cfts成员指向具体的struct cftype[]数组。下图更详细的描述了cgroup控制文件cftype错综复杂的关系。(高清大图查看方法：鼠标右键点击图片后，点击"在新标签页中打开图片"，然后在新窗口点击图片即可查看高清大图)

1  struct cftype和cfent一一对应，表示cgroup控制文件:"tasks"、release_agent、cfs_quota_us等，struct cfent靠其成员node添加到struct cgroup结构的files链表。

2  每个cgroup子系统cgroup_subsys都有一个基础cftype_set，就在cgroup_subsys结构体里。在cgroup_add_cftypes()还会再分配新的cftype_set。每个cftype_set都靠其成员node添加到cgroup_subsys的cftsets链表。

3  struct cftype_set的成员struct cftype *cfts指向cgroup子系统特有的cftype数组。主要有两类，正是前文提到的“struct cftype主要有3类”的2、3两类。

3.2 cgruop目录下文件的读写

   前一节讲解了cgroup目录和文件的创建过程，那这些文件的读写是怎么进行的呢？比如前文介绍的这些命令

1. [root@localhost cpu]# mkdir test
2. [root@localhost test]# cat cpu.cfs_quota_us
3. -1
4. [root@localhost test]# cat cpu.cfs_period_us
5. 100000
6. [root@localhost test]# echo 50000 > cpu.cfs_quota_us

cpu.cfs_quota_us这个文件是怎么读写的？

1. static struct cftype cpu_files[] = {
2.     {
3.         .name = "cfs_quota_us",//cfs进程配额
4.         .read_s64 = cpu_cfs_quota_read_s64,
5.         .write_s64 = cpu_cfs_quota_write_s64,
6.     },
7.     {
8.         .name = "cfs_period_us",//cfs进程运行周期
9.         .read_u64 = cpu_cfs_period_read_u64,
10.         .write_u64 = cpu_cfs_period_write_u64,
11.     },
12. }

echo 10000 > cpu.cfs_period_us的内核过程是sys_write()->vfs_write()->cgroup_file_write()-> cpu_cfs_period_write_u64()。可以发现先由vfs层调到cgroup文件系统的cgroup_file_write()函数，

1. static ssize_t cgroup_file_write(struct file *file, const char __user *buf,
2.                         size_t nbytes, loff_t *ppos)
3. {
4.     //通过文件dentry得到struct cfent，再由struct cfent的type得到文件的struct cftype。struct cftype包含了该cgroup文件的读写控制函数，如echo设置进程运行时间要调用的write函数
5.     struct cftype *cft = __d_cft(file->f_dentry);
6.     //通过父目录的dentry获取父目录对应的struct cgroup结构体，这个struct cgroup就代表了这个目录
7.     struct cgroup *cgrp = __d_cgrp(file->f_dentry->d_parent);
9.     //根据情况调用struct cftype *cft的write函数。echo 50000 > cpu.cfs_quota_us设置进程运行时间配额最终调用的write函数是 cpu_cfs_quota_write_s64()
10.     if (cft->write)
11.         return cft->write(cgrp, cft, file, buf, nbytes, ppos);
12.     if (cft->write_u64 || cft->write_s64)
13.         return cgroup_write_X64(cgrp, cft, file, buf, nbytes, ppos);
14.     if (cft->write_string)
15.         return cgroup_write_string(cgrp, cft, file, buf, nbytes, ppos);
16.     ......
17. }   

cpu_cfs_quota_write_s64函数源码如下：

1. static int cpu_cfs_quota_write_s64(struct cgroup *cgrp, struct cftype *cftype,
2.                 s64 cfs_quota_us)
3. {
4.     return tg_set_cfs_quota(cgroup_tg(cgrp), cfs_quota_us);
5. }
7. //设置进程组struct task_group的运行时间配额
8. int tg_set_cfs_quota(struct task_group *tg, long cfs_quota_us)
9. {
10.     u64 quota, period;
11.     //进程组的运行时间
12.     period = ktime_to_ns(tg->cfs_bandwidth.period);
13.     if (cfs_quota_us < 0)
14.         quota = RUNTIME_INF;
15.     else
16.         quota = (u64)cfs_quota_us * NSEC_PER_USEC;
18.     return tg_set_cfs_bandwidth(tg, period, quota);
19. }
21. static int tg_set_cfs_bandwidth(struct task_group *tg, u64 period, u64 quota)
22. {
23.     struct cfs_bandwidth *cfs_b = &tg->cfs_bandwidth;
24.     //进程组的运行周期和时间配额设置到进程组的struct task_group的cfs_bandwidth
25.     cfs_b->period = ns_to_ktime(period);
26.     cfs_b->quota = quota;
27. }

    可以发现，根据传入的struct cgroup结构，找到进程绑定cpu cgroup 子系统实际的struct task_group控制结构，struct  task_group保存了进程运行的时间周期、时间配额等数据。在进程调度时，如果进程运行的时间超出了struct  task_group配置的时间配额，就被迫让出CPU使用权，内核选择新的进程运行。

    每个cgroup子系统都有自己的控制结构，实现特定的功能限制。比如，进程绑定到memory cgorup子系统，对应struct mem_cgroup控制结构，保存了进程的内存分配上限，当进程分配的内存超出限制，内核会oom kill该进程；如果进程绑定到了blkio cgroup子系统，对应struct blkcg控制结构，用于限制进程的内核block层的IOPS。

   cat cpu.cfs_period_us读取的内核过程是:sys_read()->vfs_read()->cgroup_file_read()->cpu_cfs_period_read_u64()， 源码不再列了。

3 进程绑定到cgroup及css_set详解

 3.1 css_set与各个数据结构的关系

比如前文介绍的执行如下命令，将进程1绑定到cpu cgroup子系统，之后进程1的CPU使用率被限制最大50%。

1. [root@localhost cpu]# mkdir test//创建cgroup目录
2. [root@localhost test]# cat cpu.cfs_quota_us
3. -1
4. [root@localhost test]# cat cpu.cfs_period_us
5. 100000
6. [root@localhost test]# echo 50000 > cpu.cfs_quota_us
7. [root@localhost test]# echo 进程1的ID > tasks

    上一节介绍过，echo 50000 > cpu.cfs_quota_us，实际是把50000“这个进程运行时间配额值”设置到“test”这个cgroup目录对应的struct cgroup的struct  task_group中。“echo 进程1的ID > tasks”命令把进程1绑定到“test”这个cgroup目录中，之后进程1的运行时间便受该cgroup的限制。什么意思？比如进程1的函数代码是while(1);死循环，正常情况CPU使用率是100%，现在只能到50%。因为进程1绑定到“test”这个cgroup目录，该cgroup限制进程的运行时间是周期的一半，即50000/100000，100000代表进程运行周期，50000是进程在该时间内的运行时间配额。

    再啰嗦一点，centos 7.6系统，每个进程默认都绑定了每个cgroup子系统的顶层目录cgroup。什么意思？举个例子，如下：

1. [root@localhost cgroup]# sleep 999999&
2. [1] 64056 //新创建的进程PID是64056
3. [root@localhost cgroup]# cat cpu/tasks | grep 64056
4. 64056
5. [root@localhost cgroup]# cat memory/tasks | grep 64056  
6. 64056
7. [root@localhost cgroup]# cat blkio/tasks | grep 64056     
8. 64056

     所以，当我们再执行“echo 64056 > cpu/test/tasks”把进程绑定“test”这个新的cgroup目录时，只是从cpu cgroup顶层目录转移到“test”这个cgroup目录而已。

     既然每个进程都绑定了一个默认的cgroup子系统的某个层级的cgroup目录，并且每个进程可以绑定到每个cgroup子系统的每个cgroup目录。比如你可以创建N个进程都绑定到cpu cgroup“test”目录，也可以保持默认的cgroup绑定关系。当系统又上万个进程，每个进程按照自己的需求，随意绑定到cpu、memory、blkio等cgorup子系统任一个目录，这错综复杂的关系该怎么描述呢？准确说，怎么建立进程、进程绑定的所有cgroup子系统的cgroup目录的关系呢？这里引入了一个新的数据结构，struct css_set。为了理解方便，这里把前文截图有关css_set结构关系图单独贴下:

首先，进程唯一的struct task_struct结构，这个没啥说的；代表cgroup子系统的某层cgroup目录的struct cgroup结构；剩下的是两个中间牵线搭桥结构struct cg_cgroup_link和struct css_set。

1 struct task_struct通过其成员struct list_head cg_list添加到struct css_set的成员struct list_head tasks这个链表

2 struct cg_cgroup_link通过其成员struct cg_cgroup_link添加到struct css_set的成员struct list_head cg_links这个链表

3 struct cg_cgroup_link通过其成员struct list_head cgrp_link_list添加到struct cgroup的成员struct list_head css_sets这个链表

4 struct cg_cgroup_link的成员struct css_set *cg指向对应的struct css_set结构

5 struct cg_cgroup_link的成员struct cgroup *cgrp指向对应的struct cgroup结构

    显然通过这些链接关系，任一个进程，知道了struct task_struct，就可以直到它都绑定了哪些cgroup子系统的哪些cgroup目录(准确说是知道了struct cgroup结构)；同理，知道了一个cgroup目录的struct  cgroup结构，就可以找到都哪些进程(准确说是知道了struct  task_struct结构)绑定到了这个cgroup目录。

     显然，struct task_struct可以通过struct cg_cgroup_link和struct css_set找到struct cgroup。反过来struct  cgroup也可以通过struct cg_cgroup_link和struct css_set找到struct task_struct。这些错综复杂的关系是怎么建立的呢？是在进程” echo 64056 > cpu/test/tasks”绑定到cgroup目录完成的，内核过程是:sys_write->vfs_write->cgroup_file_write->cgroup_tasks_write->attach_task_by_pid->cgroup_attach_task，重点正是在cgroup_attach_task函数。

3.2  cgroup_attach_task函数讲解

 先把重点源码列下

//进程绑定到cgroup，一个进程可以绑定多个cgroup，比如cpu、memcory、blkio

1. static int cgroup_attach_task(struct cgroup *cgrp, struct task_struct *tsk,
2.                   bool threadgroup)
3. {
4.     int retval, i, group_size;
5.     struct cgroup_subsys *ss, *failed_ss = NULL;
6.     struct cgroupfs_root *root = cgrp->root;//代表cgroup子系统对应的文件系统
7.     struct task_struct *leader = tsk;
8.     struct task_and_cgroup *tc;
9.     struct flex_array *group;
10.     struct cgroup_taskset tset = { };
11.    
12.     /*分配struct flex_array，顺带着分配内存，下边执行flex_array_put()向group指向的struct flex_array填充数据，然后在下边通过flex_array_get()从group指向的struct flex_array取出数据*/
13.     group = flex_array_alloc(sizeof(*tc), group_size, GFP_KERNEL);
14.     retval = flex_array_prealloc(group, 0, group_size, GFP_KERNEL);
15.     do {
16.         struct task_and_cgroup ent;
17.         //ent.task保存待绑定进程的task_struct结构
18.         ent.task = tsk;
19.         /*找到要绑定的进程task_struct的struct css_set，依次找到css_set的cg_links链表上挂着的struct cg_cgroup_link，看哪个struct cg_cgroup_link对应的struct cgroup与本次绑定的struct cgroup属于同一个cgroup子系统。函数返回的就是从cg_cgroup_link找到的struct cgroup，其实就是找到返回该进程之前绑定的struct cgroup吧*/
20.         ent.cgrp = task_cgroup_from_root(tsk, root);
21.         /*把struct task_and_cgroup ent保存到group指向的struct flex_array，ent包含了本次待绑定的进程task_struct和该进程之前绑定的struct cgroup*/
22.         retval = flex_array_put(group, i, &ent, GFP_ATOMIC);
23.     }while_each_thread(leader, tsk);
24.    
25.     /*tset.tc_array指向新分配的struct flex_array *group，group指向struct flex_array，flex_array里保存了struct task_and_cgroup ent，ent包含了本次待绑定的进程task_struct和该进程之前绑定的struct cgroup*/
26.     tset.tc_array = group;
27.     tset.tc_array_len = group_size;//group_size是本次要绑定进程的线程数
28.    
29.     //group_size是本次要绑定进程的线程数，这是对本次绑定进程的每个线程依次处理
30.     for (i = 0; i < group_size; i++) {
31.         /*从group指向的struct flex_array，找到并返回前边保存的struct task_and_cgroup给tc。之后tc包含了本次待绑定的进程/线程的task_struct和该进程/线程之前绑定的struct cgroup。说准确点，tc->cgrp是该进程/线程之前绑定的struct cgroup，tc->task是本次要绑定的进程/线程task结构*/
32.         tc = flex_array_get(group, i);
33.         /*找到已经存在的struct css_set直接返回。否则，分配新的struct css_set *res和struct cg_cgroup_link。然后建立新分配的struct css_set *res、新分配的struct cg_cgroup_link、tc->task->cgroups链表上原有的struct cgroup或者本次要建立绑定的struct cgroup *cgrp，三者相互的联系。就是struct css_set、struct cg_cgroup_link、struct cgroup三者关系的建立*/
34.         tc->cg = find_css_set(tc->task->cgroups, cgrp);
35.     }
36.    
37.     for (i = 0; i < group_size; i++) {
38.         /*从group指向的struct flex_array，找到并返回前边保存的struct task_and_cgroup给tc。tc->cgrp是该进程之前绑定的struct cgroup，tc->task是本次要绑定的进程task结构，tc->cg是本次绑定操作新分配的struct css_set*/
39.         tc = flex_array_get(group, i);
40.         /*前边建立了struct css_set、struct cg_cgroup_link、struct cgroup的关系，这是建立待绑定进程的struct task_struct结构与绑定的struct css_set的相互联系*/
41.         cgroup_task_migrate(tc->cgrp, tc->task, tc->cg);
42.     }
43.     for_each_subsys(root, ss) {
44.         /*调用该cgroup子系统struct cgroup_subsys的atach函数，cpu 子系统时是cpu_cgroup_attach()。进程绑定了新的cpu cgroup时，要从之前cpu cgroup清理干净，然后设置进程在新的进程组的关系*/
45.         if (ss->attach)
46.             ss->attach(cgrp, &tset);
47.     }
48. }

cgroup_attach_task函数的处理未免太过啰嗦，核心点只有几个

1. 分配struct task_and_cgroup *tc结构，执行下边的do...while_each_thread(leader, tsk)把进程及其线程的task_struct、struct old css_set、struct old cgroup信息保存到struct task_and_cgroup。该函数经常从struct task_and_cgroup取出这些信息。
2. 循环执行find_css_set()，按照进程或者线程之前绑定的old css_set、本次要绑定的进程的struct cgroup *cgrp，是否有匹配的css_set，有的话直接返回这个css_set。没有找到匹配的css_set，则分配新的css_set，分配12新的struct cg_cgroup_link，把old css_set上之前进程绑定的cgroup目录struct cgroup和本次进程要绑定的cgroup目录struct cgroup *cgrp(一共12个)，按照他们所属于的cgorup子系统编号先添加到struct cg_cgroup_link，再把struct cg_cgroup_link添加到新的css_set的cg_links链表。总之就建立了新的css_set和新的cgorup的关系。
3. 循环执行执行cgroup_task_migrate(tc->cgrp, tc->task, tc->cg)，建立进程或者线程task_struct与css_set的关系

比较重要的是find_css_set()函数：找到已经存在的struct css_set直接返回。否则，分配新的struct css_set *res和root_count个struct cg_cgroup_link建立新分配的struct css_set *res、新分配的struct cg_cgroup_link、struct css_set *oldcg链表上原有的struct cgroup或者本次建立绑定的struct cgroup *cgrp，三者相互的联系。

1. static struct css_set *find_css_set(struct css_set *oldcg, struct cgroup *cgrp)
2. {
3.     struct css_set *res;
4.     struct cgroup_subsys_state *template[CGROUP_SUBSYS_COUNT];//template
5.    
6.     /*如果找到已经存在的struct css_set，我觉得struct css_set *oldcg是存在的，这是试图找到与本次绑定的struct cgroup *cgrp的匹配的struct css_set，新创建的应该都不会成立吧*/
7.     res = find_existing_css_set(oldcg, cgrp, template);
8.     if (res)
9.         return res;
10.    
11.     //分配struct css_set
12.     res = kmalloc(sizeof(*res), GFP_KERNEL);
13.     //分配root_count(应该是12)个struct cg_cgroup_link并添加到struct list_head tmp_cg_links链表，
14.     allocate_cg_links(root_count, &tmp_cg_links) < 0);
15.     //把struct cgroup_subsys_state *template[CGROUP_SUBSYS_COUNT]里所有的cgroup_subsys_state指针都复制到res->subsys[]数组
16.     memcpy(res->subsys, template, sizeof(res->subsys));
17.    
18.     /*遍历struct css_set *oldcg的cg_links链表上的已经存在的struct cg_cgroup_link, 找到其指向的struct cgroup(即link->cgrp)，然后struct cgroup *c = link->cgrp，接着把tmp_cg_links链表上的struct cg_cgroup_link移动到struct cgroup c的css_sets链表和struct css_set res的cg_links链表，还令cg_cgroup_link的成员cg和cgrp分别指向struct css_set res和struct cgroup c*/
19.     list_for_each_entry(link, &oldcg->cg_links, cg_link_list) {
20.         struct cgroup *c = link->cgrp;
21.     
22.         /*如果遍历到的老的css_set的cgroup与本次进程要绑定的cgorup属于同一个cgorup子系统，要替换成本次进程要绑定cgroup，即c = cgrp。然后下边建立本次进程要绑定cgroup和css_set的关系*/
23.         if (c->root == cgrp->root)
24.             c = cgrp;
25.         /*对tmp_cg_links上的cg_cgroup_link关键成员赋值，cg_cgroup_link的cg指向struct css_set res，cg_cgroup_link的cgrp指向struct cgroup c，后把cg_cgroup_link移动到struct cgroup的css_sets链表，把cg_cgroup_link添加到struct css_set res的cg_links链表。这样就建立了css_set、cgroup、cg_cgroup_link三者联系*/
26.         link_css_set(&tmp_cg_links, res, c);
27.     }
28.    
29.     //以struct css_set *res所有struct cgroup_subsys_state *css[]所有的cgroup子系统cgroup_subsys_state指针累加值作为hash key
30.     key = css_set_hash(res->subsys);
31.     /*通过struct css_set *res的成员hlist把css_set添加到css_set_table这个hash树，key是css_set的struct cgroup_subsys_state *css[]所有cgroup_subsys_state指针累加值*/
32.     hash_add(css_set_table, &res->hlist, key);
33. }

里边重点执行的是find_existing_css_set函数，

1. static struct css_set *find_existing_css_set(
2.     struct css_set *oldcg,
3.     struct cgroup *cgrp,
4.     struct cgroup_subsys_state *template[])//template[]在这里
5. {
6.     int i;
7.     struct cgroupfs_root *root = cgrp->root;
8.     struct css_set *cg;
9.     unsigned long key;
11.     /*for循环次数等于cgroup子系统个数（12个）。每次循环取出一个cgroup子系统的cgroup_subsys_state赋值于template[]。大部分都是从oldcg->subsys[i]取cgroup_subsys_state赋于template[i]。只有if (root->subsys_mask & (1UL << i))成立，说明本次循环遍历到了本次进程要绑定的struct cgroup *cgrp对应的cgroup子系统，则从cgrp->subsys[i]取出cgroup_subsys_state赋于template[i]*/
12.     for (i = 0; i < CGROUP_SUBSYS_COUNT; i++) {
13.         /*这轮循环是本次进程要绑定的struct cgroup *cgrp对应的cgroup子系统，从本次进程要绑定的cgroup获取对应的cgroup_subsys_state
14.         if (root->subsys_mask & (1UL << i)) {
15.             template[i] = cgrp->subsys[i];
16.         } else {
17.              //从old cgroup获取对应的cgroup_subsys_state
18.             template[i] = oldcg->subsys[i];
19.         }
20.     }
21.     /*hash key是template[]里所有的cgroup_subsys_state指针。此时template[]里的cgroup_subsys_state结合了老的oldcg和新的cgrp这两个cgroup的struct cgroup->subsys[]里所有的cgroup_subsys_state*/
22.     key = css_set_hash(template);
23.     //遍历所有的css_set_table hash链表上的css_set，
24.     hash_for_each_possible(css_set_table, cg, hlist, key) {
25.         if (!compare_css_sets(cg, oldcg, cgrp, template))
26.             continue;
27.         return cg;
28.     }
29.     return NULL;
30. }

find_existing_css_set()是结合进程之前绑定的oldcg和本次绑定的cgroup目录cgrp，在css_set_table链表找到一个匹配的css_set，找到则返回css_set，否则返回NULL。查找规则是什么呢?我们把find_existing_css_set函数拆解成3步分详细说说。

1在for (i = 0; i < CGROUP_SUBSYS_COUNT; i++)循环那里使用cgrp->subsys[i]和oldcg->subsys[i]的cgroup_subsys_state填充template[CGROUP_SUBSYS_COUNT]数组。除了for循环遍历到了本次进程要绑定的struct cgroup *cgrp对应的cgroup子系统，是从cgrp->subsys[i]取出cgroup_subsys_state赋于template[i]，即template[i] = cgrp->subsys[i]。其他都是template[i] = oldcg->subsys[i]

2  之后template[i]的cgroup_subsys_state就结合了老css_set和本次要绑定进程的cgroup的cgroup_subsys_state，以template[i]为key在css_set_table链表查找匹配的css_set，这里称为css_set_new。css_set_new->subsys[i]和template[i]的cgroup_subsys_state应该完全一样，毕竟是以template[i]的cgroup_subsys_state为key在css_set_table链表找到的css_set_new。

3  接着执行compare_css_sets()循环遍历css_set_new和struct css_set *oldcg的cg_links链表上的cg_cgroup_link指向的cgroup，简单说就是css_set绑定的struct cgroup而已。然后结合本次进程要绑定的struct cgroup *cgrp，判断3者是否相等。具体规则是:每次循环，遍历到css_set_new和struct css_set *oldcg上的cgroup如果不相等，直接返回false ; 如果本次循环从css_set_new遍历到的cgroup与本次进程要绑定的struct cgroup *cgrp都属于同一个cgroup子系统(cgroup->cgroupfs_root相等)，但是两个cgroup不相等，说明不是同一个cgroup目录，返回false。如果经过前边的判断全都不成立，则返回true。这说明css_set_new就是本次进程绑定的css_set。

compare_css_sets函数源码如下：

1. static bool compare_css_sets(struct css_set *cg,
2.                  struct css_set *old_cg,
3.                  struct cgroup *new_cgrp,
4.                  struct cgroup_subsys_state *template[]
5. {
6.     //l1和l2指向css_set的 struct list_head cg_links
7.     l1 = &cg->cg_links;
8.     l2 = &old_cg->cg_links;
9.     while (1) {
10.         struct cg_cgroup_link *cgl1, *cgl2;
11.         struct cgroup *cg1, *cg2;
12.         //l1 = l1->next赋值后，l1才指向struct cg_cgroup_link的cg_link_list成员，然后list_entry()再找到struct cg_cgroup_link。l2同理
13.         l1 = l1->next;//下边list_entry()由l1指向的cg_link_list得到cg_cgroup_link
14.         l2 = l2->next;//下边list_entry()由l2指向的cg_link_list得到cg_cgroup_link
15.         BUG_ON(cg1->root != cg2->root);
16.         //由l1和l2指向的cg_link_list分别得到各自的cg_cgroup_link
17.         cgl1 = list_entry(l1, struct cg_cgroup_link, cg_link_list);
18.         cgl2 = list_entry(l2, struct cg_cgroup_link, cg_link_list);
19.         //再由cg_cgroup_link得到cgroup
20.         cg1 = cgl1->cgrp;
21.         cg2 = cgl2->cgrp;
22.         /*cg1->root == new_cgrp->root，说明本次循环遍历到的css_set_table链表上的css_set的cg_links链表上的cgroup和本次的new_cgrp属于同一个cgroup子系统.那就再看看这两个cgroup是否是cgroup目录(即if(cg1 != new_cgrp))，如果不是同一个cgroup，返回flase*/
23.         if (cg1->root == new_cgrp->root) {
24.             if (cg1 != new_cgrp)
25.                 return false;
26.         } else {
27.         //其他情况，css_set_table链表上的css_set的cg_links链表上的cgroup和old_cg的cg_links链表上的cgroup不相等，直接返回false
28.             if (cg1 != cg2)
29.                 return false;
30.         }
31.     }
32.     return true;
33. }

   compare_css_sets()循环遍历struct css_set *cg和struct css_set *oldcg的cg_links链表上的cg_cgroup_link指向的cgroup，简单说就是css_set绑定的struct cgroup而已。然后结合本次进程要绑定的struct cgroup *cgrp，判断3者是否相等。具体规则是:每次循环，遍历到struct css_set *cg和struct css_set *oldcg上的cgroup如果不相等，直接返回false ; 如果本次循环从struct css_set *cg遍历到的cgroup与本次进程要绑定的struct cgroup *cgrp都属于同一个cgroup子系统(cgroup->cgroupfs_root相等)，但是两个cgroup不相等，说明不是同一个cgroup目录，返回false。如果经过前边的判断全都不成立，则返回true。这说明struct css_set *cg就是本次进程要绑定的css_set。

   每一个进程绑定的css_set的 cg_links链表上，一定有12个struct cg_cgroup_link，对应12个cgroup子系统的cgroup目录。这些12个cgroup子系统的cgroup目录是按照cgroup子系统的编号顺序排列在css_set的 cg_links链表上。compare_css_sets函数的for循环就是取出struct css_set *cg和struct css_set *old_cg这两个css_set的cg_links链表的struct cg_cgroup_link对应的cgorup目录结构的struct cgroup，由于cgroup是按照cgroup子系统编号顺序排列在css_set的 cg_links链表上，所以每轮循环从struct css_set *cg和struct css_set *old_cg取出的struct cgroup一定属于同一个cgroup子系统，所以BUG_ON(cg1->root != cg2->root)一定不成立。并且，这两个css_set肯定都只有12个cgroup，所以BUG_ON(l2 != &old_cg->cg_links)也不成立。但是每轮循环从struct css_set *cg和struct css_set *old_cg取出的struct cgroup cgroup目录结构不一定一样，因为对应的两个进程绑定的cgroup目录不一定一样，这样就匹配失败。

    是不是感觉css_set很复杂，我一次看的时候相当迷茫，其实这个问题从全局反而不容易陷入代码泥潭。

3.3 css_set更深层次的解释

进程"echo 进程ID >cpu/tasks"绑定cgroup目录,执行函数cgroup_attach_task->find_css_set->find_existing_css_set->compare_css_sets()，如果找到匹配的css_set，直接把进程task_struct与css_set建立关系即可。如果找不到就要分配新的css_set、struct cg_cgroup_link，然后用进程之前绑定的old css_set的cg_links链表上的cg_cgroup_link对应的cgroup结构以及本次绑定的cgorup目录结构，建立3者的关系。最后，建立进程task_stuct与新的css_set的关系，步骤如下：

1    首先是find_existing_css_set函数里，向css_set的subsys[i]数组保存cgroup_subsys_state:进程绑定cgroup目录时执行到cgroup_attach_task->find_css_set->find_existing_css_set()函数，该函数里执行template[i] = cgrp->subsys[i]。cgrp是本次进程要绑定的cgroup目录结构，i是本次进程要绑定的cgroup目录对应的cgroup子系统编号，cgrp->subsys[i]就是cgroup目录对应的cgroup_subsys_state。后边在find_css_set()里会把template[i]的所有cgroup_subsys_state复制到css_set的subsys[i]数组，下边有讲。所以css_set->subsys[]里的cgroup_subsys_state来自进程要绑定的cgroup目录对应的cgroup控制结构(比如cpu cgroup子系统的struct task_group)的cgroup_subsys_state成员。如果一个进程没有绑定cgroup目录，那对应css_set->subsys[i]里的cgroup_subsys_state都是从父进程继承的默认的cgroup_subsys_state。之后进程每绑定一个cgroup目录，就要把这个cgroup目录对应的cgroup控制结构(比如cpu cgroup子系统的struct task_group)的成员cgroup_subsys_state按照该cgroup子系统编号保存到css_set->subsys[i]，i是cgroup子系统编号。

2  如果在find_css_set->find_existing_css_set()中找到了进程要绑定css_set则直接返回该css_set，然后在cgroup_attach_task()将进程的task_struct结构绑定到返回的css_set即可(见2.6)。如果没有找到要绑定的css_set，则find_css_set->find_existing_css_set()返回NULL，这种情况很复杂，需要分配新的css_set。并且要把进程之前绑定的old css_set的成员cg_links链表上的cg_cgroup_link指向的所有cgroup结构迁移到新的css_set，说到底就是要把进程之前绑定的所有其他cgroup子系统的cgroup目录结构转移到新的css_set。这些是在find_css_set()函数后期执行的，步骤是:

      2.1 执行 struct css_set *res = kmalloc(sizeof(*res), GFP_KERNEL)分配新的css_set
    2.2 执行 allocate_cg_links(root_count, &tmp_cg_links) 为新的css_set分配新的struct cg_cgroup_link
   2.3 执行 memcpy(res->subsys, template, sizeof(res->subsys))把template[]所有的cgroup_subsys_state复制到struct css_set *res的subsys[]数组。
  2.4 执行 link_css_set(&tmp_cg_links, res, c) 建立新的css_set、新的struct cg_cgroup_link、进程之前绑定的old css_set的cg_links链表上的cg_cgroup_link对应的cgroup结构以及本次绑定的cgorup目录结构，三者的关系。
   2.5 执行 key = css_set_hash(res->subsys) 和 hash_add(css_set_table, &res->hlist, key)，以新的css_set的subsys[]保存的cgroup_subsys_state为key，把新的css_set加入css_set_table链表。每个css_set都是以这种形式加入到css_set_table链表，将来也是按照同样方法计算css_set的key，然后从css_set_table链表链表找到对应的css_set。
   2.6 接着从cgroup_attach_task->find_css_set()返回到cgroup_attach_task函数，执行cgroup_task_migrate(tc->cgrp, tc->task, tc->cg)建立本次要绑定cgroup目录的进程的task_struct结构与新的css_set的关系。

css_set 的存在意义到底是什么？

     css_set的存在就是为了记录进程绑定的所有的cgroup目录结构，一个进程可以绑定到cpu、blkio、memory等12个cgroup子系统。准确说，一个新创建的进程默认就绑定了12个cgroup子系统，对应1个struct css_set，12个struct cg_cgroup_link，12个struct cgroup，这12个struct cgroup按照他们的cgroup子系统编号顺序链入struct cg_cgroup_link，struct cg_cgroup_link再链入struct css_set的cg_links成员。所以说，css_set的cg_links的链表上的cg_cgroup_link对应的sturct cgroup，第一个的cgroup子系统编号是0，第2个cgroup子系统编号是1，其他类推。总之这些struct cgroup就是按照cgroup子系统编号排列的。

    之后进程1绑定cpu、blkio、memory等新的cgroup目录时(比如cpu/test/tasks)，需要分配新一个css_set，12个struct cg_cgroup_link。然后把进程之前绑定old css_set的cg_links的链表上的cg_cgroup_link对应的sturct cgroup和本次进程要绑定的新cgroup目录的struct cgroup (碰到同一个cgroup子系统的struct cgroup，要踢掉old css_set的这个struct croup，而使用本次要绑定的新cgroup目录的struct cgroup)，按照cgroup子系统编号依次转移到新分配的12个struct cg_cgroup_link上，这12个struct cg_cgroup_link再按照顺序链入新分配的css_set的cg_links链表。这个过程就对应find_css_set->find_existing_css_set()没有找到匹配css_set的情况。

     然后再有创建的进程2，把它绑定也绑定到"cpu/test/tasks"。此时进程1和进程2绑定的cgroup子系统和cgroup目录完全一样，直接找到了上一次进程绑定"cpu/test/tasks"时分配css_set直接返回即可。这个过程就对应find_css_set->find_existing_css_set()找到匹配css_set的情况。

进程绑定的css_set有什么规律?

1. 1 进程绑定cgroup时，一定是从一个老的cgroup转移到新的cgroup，进程的cgroup信息继承父进程的，原始父进程绑定的有默认的cgroup。
2. 2 两个进程绑定的cgroup层级、cgroup子系统、cgroup目录完全一致时，二者绑定的css_set是同一个。进程1绑定cpu/tasks和memory/tasks，进程2绑定cpu/tasks和memory/test/tasks，二者绑定的css_set不相同。
3. 3 一个进程只会绑定一个see_set，不管绑定多少个cgroup子系统、绑定到哪个cgroup目录，无非绑定的css_set变来变去。并且进程绑定一个cgroup目录后，它绑定的css_set的subsys[]数组要保存该cgroup目录对应的cgroup控制结构(比如cpu cgroup子系统的struct task_group)的成员cgroup_subsys_state地址，保存在subsys[]数组什么位置呢?由该cgroup目录对应的cgroup子系统编号决定。

      为了能彻底的解释清楚，举个例子，重点来了。

• 进程1绑定"cpu/tasks"(cgroup目录是cgroup1)和"memory/tasks"(cgroup目录是cgroup2)，绑定的css_set是css_set1。
• 进程2绑定"cpu/tasks"(cgroup目录是cgroup1)和"memory/test/tasks"(cgroup目录是cgroup3)，绑定的css_set是css_set2。
• css_set1->subsys[12]={... ,cgroup1对应的cgroup_subsys_state, ... ,cgroup2对应的cgroup_subsys_state,}
• css_set2->subsys[12]={... ,cgroup1对应的cgroup_subsys_state, ... , cgroup3对应的cgroup_subsys_state,}

这两个css_set都以css_set->subsys[]的cgroup_subsys_state指针为key加入到css_set_table链表。

继续，进程2改为绑定"memory/tasks"，执行到cgroup_attach_task->find_css_set->find_existing_css_set()函数，

       for (i = 0; i < CGROUP_SUBSYS_COUNT; i++)中对template[i]赋值，赋值后是

• template[12]={...,cgroup1对应的cgroup_subsys_state,...,cgroup2对应的cgroup_subsys_state,}

然后执行key = css_set_hash(template)，以template[12]里边12个cgroup子系统的cgroup_subsys_state指针为key，在css_set_table链表找到css_set1。然后执行compare_css_sets(css_set1, css_set2, cgroup2, template)函数，进行匹配校验。主要匹配两点：

1  循环从css_set_table上找到css_set，找到css_set1时，从css_set1和进程2之前绑定的css_set2的cg_links的链表上的取出cg_cgroup_link，再得到cg_cgroup_link对应的struct cgroup，比较两个struct cgroup是否相等(实际是按照cgroup子系统的编号成对比较)，比较11次(一共12 cgroup子系统)，有一对不相等返回false。

2 在第一步的基础上，还有1次就是从css_set1取出的struct cgroup与进程2本次要绑定的"memory/tasks"的cgroup2属于同一个cgroup子系统，则要判断两个struct cgroup是否相等，不相等返回false。这些判断都通过，说明从css_set_table上找到的css_set1，就是进程绑定"memory/tasks"cgroup目录要绑定的css_set，css_set匹配成功。然后回到cgroup_attach_task函数，执行cgroup_task_migrate()把进程2的task_struct绑定到css_set1，暂时完工。

      如果进程2改为绑定"memory/test2/tasks"(cgroup目录是cgroup5)，执行到cgroup_attach_task->find_css_set->find_existing_css_set()函数，同样执行到for (i = 0; i < CGROUP_SUBSYS_COUNT; i++)中对template[i]赋值，赋值后是

template[i]={...,cgroup1对应的cgroup_subsys_state,...,cgroup5对应的cgroup_subsys_state,}

      显然find_existing_css_set()中找不到匹配的css_set则返回NULL。然后回到find_css_set()，分配新的css_set3，分配12个struct cg_cgroup_link，再取出进程2之前绑定的css_set2的成员cg_links的链表上的cg_cgroup_link对应的struct cgroup(一共12个)，依次把这12个struct cgroup按照cgroup子系统编号先加入cg_cgroup_link，再把cg_cgroup_link加入到css_set3的cg_links链表。

      添加过程如果碰到struct cgroup与进程2要绑定"memory/test2/tasks" (cgroup目录是cgroup5)一致，是要把cgroup5添加到cg_cgroup_link链表，再把cg_cgroup_link加入到css_set3的cg_links链表。这个过程在find_css_set()函数的如下代码完成

1.        list_for_each_entry(link, &oldcg->cg_links, cg_link_list)
2.        { 
3.            //如果遍历到的老的css_set的cgroup与本次进程要绑定的cgorup属于同一个cgorup子系统，要替换成本次进程要绑定cgroup，然后下边建立本次进程要绑定cgroup5、css_set3的关系
4.            if (c->root == cgrp->root)
5.                c = cgrp;
6.            //设置进程task_struct结构与css_set的关系
7.            link_css_set(&tmp_cg_links, res, c);
8.        }

     最后回到cgroup_attach_task函数，执行cgroup_task_migrate()把进程2的task_struct绑定到css_set3，完工。

     如图，进程1、进程2、进程3都绑定到了cpu子系统的/sys/fs/cgroup/cpu/test1目录和memory子系统的/sys/fs/cgroup/memory/test1目录，3者绑定的其他的cgroup子系统的cgroup目录都是默认的的根目录，总计12个cgroup子系统。3个进程绑定的css_set都是css_set1。正如前文所说，centos 7.6系统，每个新创建的进程默认都绑定到了12个cgroup子系统的根目录，之后进程绑定到某个新的cgroup目录，无非是从老的cgroup目录移动到新的，比如进程1默认绑定cpu子系统的/sys/fs/cgroup/cpu这个cgroup目录，现在绑定到了/sys/fs/cgroup/cpu/test1这个cgroup目录。

   现在进程1改变cpu子系统的绑定目录，由” /sys/fs/cgroup/cpu/test1”改为” /sys/fs/cgroup/cpu/test2”，它绑定的css_set变为css_set2。进程2和进程3绑定的cgroup目录不变，二者绑定的css_set还是css_set1。前文也提过，一个进程绑定的cgroup目录只要有一个发生变化，它绑定的css_set就要变。

    两个进程绑定的cgroup子系统和cgroup目录只有完全一样，它们绑定的css_set才是同一个。struct css_set结构的成员struct cgroup_subsys_state *subsys[]保存的它对应的12个cgroup子系统的cgroup目录对应的具体控制结构(cpu子系统的是struct  task_group)的成员struct cgroup_subsys_state css的地址。struct  task_group、struct cgroup_subsys_state css、cgroup目录对应的struct cgroup  三者一一对应，在创建目录时分配。所以说，css_set的struct cgroup_subsys_state *subsys[]保存的其实是每个cgroup目录的唯一信息，进程绑定的cgroup目录完全一样，绑定的css_set就是同一个。

     css_set以其成员struct cgroup_subsys_state *subsys[]保存的所有cgroup_subsys_state指针累计为hash key，保存在css_set_table链表。一个进程绑定一个新的cgroup目录时，以绑定的cgroup目录对应的cgroup_subsys_state指针加上绑定的其他cgroup子系统cgroup目录对应的cgroup_subsys_state指针，在css_set_table链表查找匹配css_set。如果之前已经有进程绑定的cgroup目录与这个进程本次绑定的完全一致，则直接返回css_set即可，否则就要分配新的css_set。好了，感觉说的太啰嗦了，上边的示意图说明的比较充分。

参考

https://www.cnblogs.com/acool/p/6852250.html

Linux cgroup机制分析之框架分析-xgr180-ChinaUnix博客

https://www.cnblogs.com/lisperl/archive/2012/04/18/2455027.html

Linux资源管理之cgroups简介 - 美团技术团队

https://www.cnblogs.com/acool/p/6882644.html