? ? ?cgroup的原理其实并不复杂，用法也比较简单。但是涉及的内核数据结构真的复杂，错综复杂的数据结构感觉才是cgroup真正的难点。本文结合个人学习cgroup源码的心得，尽可能以举例的形式，总结cgroup整体框架和核心源码实现，尽可能少贴源码。本次是在centos 7.6测试的cgroup，源码注释基于3.10.96。
这里先把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层级，如下是从https://tech.meituan.com/2015/03/31/cgroups.html 直接贴过来的演示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 cpu]# mkdir 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
static long cgroup_create(struct cgroup *parent, struct dentry *dentry,//dentry是新创建的目录的dentry
???????????????? umode_t mode)
{
??? struct cgroup *cgrp;
??? struct cgroupfs_root *root = parent->root;
?? ?//分配本次的cgroup结构体，一个目录对应一个struct cgroup
??? cgrp = kzalloc(sizeof(*cgrp), GFP_KERNEL);
??? //指向本cgroup对应目录的dentry
??? cgrp->dentry = dentry;
??? //cgroup的parent
??? cgrp->parent = parent;
??? //指向根cgroupfs_root
??? cgrp->root = parent->root;
??? //遍历cgroupfs_root->subsys_list链表，找到该链表上的cgroup_subsys，即cgroup子系统，然后执行该cgroup子系统的css_alloc()函数
??? for_each_subsys(root, ss) {
??????? //分配cgroup子系统的控制结构(如cpu的是task_group)，返回task_group结构的第一个成员struct cgroup_subsys_state css的地址赋于css
??????? css = ss->css_alloc(cgrp);//cpu子系统是cpu_cgroup_css_alloc()
??????? //初始化struct cgroup_subsys_state css，并赋值cgrp->subsys[ss->subsys_id]=css
??????? init_cgroup_css(css, ss, cgrp);
??? }
??? //创建该目录的inode，建立dentry和inode的关系
??? err = cgroup_create_file(dentry, S_IFDIR | mode, sb);
??? //生成该cgroup目录下相关子系统的控制文件，如"tasks"、"notify_on_release"等
??? err = cgroup_populate_dir(cgrp, true, root->subsys_mask);
}
?? 这个函数一下引出了很多数据结构，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结构。
struct cgroup_subsys cpu_cgroup_subsys = {
??? .name?????? = "cpu",
??? .css_alloc? = cpu_cgroup_css_alloc,//创建cpu cgroup具体的控制单元task_group
??? .css_free?? = cpu_cgroup_css_free,
??? .css_online = cpu_cgroup_css_online,
??? .css_offline??? = cpu_cgroup_css_offline,
??? .can_attach = cpu_cgroup_can_attach,
??? .attach???? = cpu_cgroup_attach,
??? .exit?????? = cpu_cgroup_exit,
??? .subsys_id? = cpu_cgroup_subsys_id,//cpu cgroup子系统的id是cpu_cgroup_subsys_id
??? .base_cftypes?? = cpu_files, //cpu cgroup子系统独有的控制文件
??? .early_init = 1,
}
struct cgroup_subsys mem_cgroup_subsys = {
??? .name = "memory",
??? .subsys_id = mem_cgroup_subsys_id,
??? .css_alloc = mem_cgroup_css_alloc,
??? .css_online = mem_cgroup_css_online,
??? .css_offline = mem_cgroup_css_offline,
??? .css_free = mem_cgroup_css_free,
??? .can_attach = mem_cgroup_can_attach,
??? .cancel_attach = mem_cgroup_cancel_attach,
??? .attach = mem_cgroup_move_task,
??? .bind = mem_cgroup_bind,
??? .base_cftypes = mem_cgroup_files,//memory cgroup子系统独有的控制文件
??? .early_init = 0,
??? .use_id = 1,
};
struct cgroup_subsys blkio_subsys = {
??? .name = "blkio",
??? .css_alloc = blkcg_css_alloc,
??? .css_offline = blkcg_css_offline,
??? .css_free = blkcg_css_free,
??? .can_attach = blkcg_can_attach,
??? .subsys_id = blkio_subsys_id,
??? .base_cftypes = blkcg_files,
??? .module = THIS_MODULE,
??? .broken_hierarchy = true,
};
每个cgroup子系统的struct cgroup_subsys结构最终是保存在struct cgroup_subsys *subsys[CGROUP_SUBSYS_COUNT]全局结构体指针数组中，如下:
#define SUBSYS(_x) [_x ## _subsys_id] = &_x ## _subsys,
static struct cgroup_subsys *subsys[CGROUP_SUBSYS_COUNT] = {
#include <linux/cgroup_subsys.h>
SUBSYS(cpuset)
SUBSYS(debug)
SUBSYS(cpu_cgroup)//限制CPU
SUBSYS(cpuacct)
SUBSYS(mem_cgroup)//限制mem
SUBSYS(devices)
SUBSYS(freezer)
SUBSYS(net_cls)
SUBSYS(blkio)//限制block
SUBSYS(net_prio)
SUBSYS(hugetlb)
};
把这些结构体拆开简化后如下：
static struct cgroup_subsys *subsys[CGROUP_SUBSYS_COUNT] = {
………
[cpuset_subsys_id] = cpu_cgroup_subsys,
………
[mem_cgroup_subsys_id] = mem_cgroupt_subsys,
[blkio_subsys_id] = blkio_subsys,
………
};
终于看到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()函数的关键源码。
static int cgroup_populate_dir(struct cgroup *cgrp, bool base_files,
?????????????????? unsigned long subsys_mask)
{
??? struct cgroup_subsys *ss;
??? //从struct cftype files[]全局结构体获取cgroup基本的文件cftype，比如"task"、"release_agent"等基本cgroup文件，然后在cgroup子系统的目录下创建这些基本文件*/
??? if (base_files) {
??????? err = cgroup_addrm_files(cgrp, NULL, files, true);
??? }
?? /*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文件。*/
??? for_each_subsys(cgrp->root, ss) {
??????? struct cftype_set *set;
??????? /*这是限定只有与subsys_mask指定的cgroup子系统匹配才能执行下边的cgroup_addrm_files()创建特定cgroup子系统的cgroup文件。比如在cpu cgroup目录下创建cgroup文件，该if只有是ss是cpu的cgroup_subsys才不成立*/
??????? if (!test_bit(ss->subsys_id, &subsys_mask))
??????????? continue;
???????
??????? /*遍历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结构体描述。*/
??????? list_for_each_entry(set, &ss->cftsets, node)
??????????? cgroup_addrm_files(cgrp, ss, set->cfts, true);
??? }
}
static int cgroup_addrm_files(struct cgroup *cgrp, struct cgroup_subsys *subsys,
????????????????? struct cftype cfts[], bool is_add)
{
??? struct cftype *cft;
??? //依次取出struct cftype files定义的文件
??? for (cft = cfts; cft->name[0] != '\0'; cft++) {
??????? //cft指向struct cftype files[]定义的每个基本文件结构。以cft指向成员内容，创建cgroup下的文件，常见的"tasks"等等,
??????? cgroup_add_file(cgrp, subsys, cft);
??? }
}
//以cft指向成员内容，创建cgroup下的文件，常见的"tasks"等等
static int cgroup_add_file(struct cgroup *cgrp, struct cgroup_subsys *subsys,
?????????????? struct cftype *cft)//创建cgroup基本文件时，cft指向struct cftype files[]定义的每个基本文件结构
{
??? //cgroup子系统父目录的dentry，下边就是在这个dentry下创建cgroup子文件"tasks"等等
??? struct dentry *dir = cgrp->dentry;
??? struct cgroup *parent = __d_cgrp(dir);
??? struct dentry *dentry;
??? struct cfent *cfe;
???
??? //文件名字，比如"tasks"
??? strcat(name, cft->name);
??? //分配cfe，cfe代表了一个cgroup目录下的的cgroup文件
??? cfe = kzalloc(sizeof(*cfe), GFP_KERNEL);
??? //在父目录base下，查找或者创建name指定的文件dentry
??? dentry = lookup_one_len(name, dir, strlen(name));
??? //cfe保存这个cgroup文件的基本信息
??? cfe->type = (void *)cft;
??? cfe->dentry = dentry;
??? dentry->d_fsdata = cfe;
??? //分配文件的inode，建立inode和dentry联系，成功返回0
??? error = cgroup_create_file(dentry, mode | S_IFREG, cgrp->root->sb);
??? //把新分配的cfe添加到cgroup父目录的struct cgroup的files链表
??? list_add_tail(&cfe->node, &parent->files);
}
一下又冒出了几个结构体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[]
static struct cftype files[] = { //这个是 cgroup子系统的基本文件
??? {
??????? .name = "tasks",
??????? .open = cgroup_tasks_open,
??????? .write_u64 = cgroup_tasks_write,//绑定每个进程
??????? .release = cgroup_pidlist_release,
??????? .mode = S_IRUGO | S_IWUSR,
??? },
??? {
??????? .name = CGROUP_FILE_GENERIC_PREFIX "procs",
??????? .open = cgroup_procs_open,
??????? .write_u64 = cgroup_procs_write,
??????? .release = cgroup_pidlist_release,
??????? .mode = S_IRUGO | S_IWUSR,
??? },
??? {
??????? .name = "notify_on_release",
??????? .read_u64 = cgroup_read_notify_on_release,
??????? .write_u64 = cgroup_write_notify_on_release,
??? },
??? .............
};
但是每个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子系统特有的控制文件结构体，如下：
static struct cftype cpu_files[] = {
??? {
??????? .name = "cfs_quota_us",//cfs进程运行时间配额
??????? .read_s64 = cpu_cfs_quota_read_s64,
??????? .write_s64 = cpu_cfs_quota_write_s64,
??? },
??? {
??????? .name = "cfs_period_us",//cfs进程运行周期
??????? .read_u64 = cpu_cfs_period_read_u64,
??????? .write_u64 = cpu_cfs_period_write_u64,
??? },
??? {
??????? .name = "stat",
??????? .read_map = cpu_stats_show,
??? }
}
blkio cgroup子系统独有的控制文件结构体数组struct cftype throtl_files[]
static struct cftype throtl_files[] = {
??? ..........
??? {
??????? .name = "throttle.read_iops_device",
??????? .private = offsetof(struct throtl_grp, iops[READ]),
??????? .read_seq_string = tg_print_conf_uint,
??????? .write_string = tg_set_conf_uint,
??????? .max_write_len = 256,
??? },
??? {
??????? .name = "throttle.write_iops_device",
??????? .private = offsetof(struct throtl_grp, iops[WRITE]),
??????? .read_seq_string = tg_print_conf_uint,
??????? .write_string = tg_set_conf_uint,
??????? .max_write_len = 256,
??? },
??? ..........
}
memory cgroup子系统控制文件结构体数组struct cftype mem_cgroup_files []
static struct cftype mem_cgroup_files[] = {
??? {
??????? .name = "usage_in_bytes",
??????? .private = MEMFILE_PRIVATE(_MEM, RES_USAGE),
??????? .read = mem_cgroup_read,
??????? .register_event = mem_cgroup_usage_register_event,
??????? .unregister_event = mem_cgroup_usage_unregister_event,
??? },
??? {
??????? .name = "max_usage_in_bytes",
??????? .private = MEMFILE_PRIVATE(_MEM, RES_MAX_USAGE),
??????? .trigger = mem_cgroup_reset,
????? ??.read = mem_cgroup_read,
??? },
??? {
??????? .name = "limit_in_bytes",//设置进程内存使用
??????? .private = MEMFILE_PRIVATE(_MEM, RES_LIMIT),
??????? .write_string = mem_cgroup_write,
??????? .read = mem_cgroup_read,
??? },
??? .........
}
以上提到的这些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[]，如下：
struct cgroup_subsys cpu_cgroup_subsys = {
??? .name?????? = "cpu",
??? .css_alloc? = cpu_cgroup_css_alloc,
??? .css_free? ?= cpu_cgroup_css_free,
??? .css_online = cpu_cgroup_css_online,
??? .css_offline??? = cpu_cgroup_css_offline,
??? .can_attach = cpu_cgroup_can_attach,
??? .attach???? = cpu_cgroup_attach,
??? .exit?????? = cpu_cgroup_exit,
??? .subsys_id? = cpu_cgroup_subsys_id,
??? .base_cftypes?? = cpu_files,
??? .early_init = 1,
};
cpu cgroup子系统struct cgroup_subsys的base_cftypes成员指向的struct cftype cpu_files[]是怎么添加到cgroup相关的数据结构呢？这是在cgroup子系统模块初始化cgroup_init->cgroup_init_subsys()->cgroup_init_cftsets，源码如下：
int __init cgroup_init(void)
{
??? for (i = 0; i < CGROUP_SUBSYS_COUNT; i++) {
? ??????//从subsys[]按照cgroup子系统编号依次取出 cpuset_subsys 、 blkio_subsys等这些cgroup子系统结构体struct cgroup_subsys
??????? struct cgroup_subsys *ss = subsys[i];
??????? cgroup_init_subsys(ss);//cpu、mem、cgroup等cgroup_subsys结构初始化赋值
??? }
}
static void __init cgroup_init_subsys(struct cgroup_subsys *ss)
{
??? cgroup_init_cftsets(ss);//初始化cpu、memcory、block 的cgroup文件
??? list_add(&ss->sibling, &rootnode.subsys_list);//cgroup_subsys添加到subsys_list链表
??? ss->root = &rootnode;//cgroup_subsys->root 指向rootnode
???
??? css = ss->css_alloc(dummytop);//分配顶层cgroup的struct cgroup_subsys_state
?? ?init_cgroup_css(css, ss, dummytop);//初始化顶层cgorup的struct cgroup_subsys_state
}
static void __init_or_module cgroup_init_cftsets(struct cgroup_subsys *ss)
{
??? INIT_LIST_HEAD(&ss->cftsets);
??? if (ss->base_cftypes) {
??????? //cgroup_subsys的cftype_set的cfts指向cgroup子系统cgroup_subsys的成员base_cftypes指向的struct cftype数组
??????? ss->base_cftset.cfts = ss->base_cftypes;
??????? //把cgroup子系统struct cgroup_subsys的成员base_cftypes指向的struct cftype数组添加到cgroup子系统struct cgroup_subsys的cftsets链表
??????? list_add_tail(&ss->base_cftset.node, &ss->cftsets);
??? }
}
除了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链表
int cgroup_add_cftypes(struct cgroup_subsys *ss, struct cftype *cfts)
{
??? struct cftype_set *set;
??? //分配cftype_set
??? set = kzalloc(sizeof(*set), GFP_KERNEL);
??? if (!set)
??????? return -ENOMEM;
??? cgroup_cfts_prepare();
??? //cftype_set的cfts指向cftype数组
??? set->cfts = cfts;
??? //cftype_set靠其node成员添加到cgroup_subsys的cftsets链表
??? list_add_tail(&set->node, &ss->cftsets);
??? cgroup_cfts_commit(ss, cfts, true);
??? return 0;
}
? ? 这些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目录和文件的创建过程，那这些文件的读写是怎么进行的呢？比如前文介绍的这些命令
[root@localhost cpu]# mkdir test
[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
cpu.cfs_quota_us这个文件是怎么读写的？
static struct cftype cpu_files[] = {
??? {
??????? .name = "cfs_quota_us",//cfs进程配额
??????? .read_s64 = cpu_cfs_quota_read_s64,
? ??????.write_s64 = cpu_cfs_quota_write_s64,
??? },
??? {
??????? .name = "cfs_period_us",//cfs进程运行周期
??????? .read_u64 = cpu_cfs_period_read_u64,
??????? .write_u64 = cpu_cfs_period_write_u64,
??? },
}
echo 10000 > cpu.cfs_period_us的内核过程是sys_write()->vfs_write()->cgroup_file_write()-> cpu_cfs_period_write_u64()。可以发现先由vfs层调到cgroup文件系统的cgroup_file_write()函数，
static ssize_t cgroup_file_write(struct file *file, const char __user *buf,
??????????????????????? size_t nbytes, loff_t *ppos)
{
??? //通过文件dentry得到struct cfent，再由struct cfent的type得到文件的struct cftype。struct cftype包含了该cgroup文件的读写控制函数，如echo设置进程运行时间要调用的write函数
??? struct cftype *cft = __d_cft(file->f_dentry);
??? //通过父目录的dentry获取父目录对应的struct cgroup结构体，这个struct cgroup就代表了这个目录
??? struct cgroup *cgrp = __d_cgrp(file->f_dentry->d_parent);
??? //根据情况调用struct cftype *cft的write函数。echo 50000 > cpu.cfs_quota_us设置进程运行时间配额最终调用的write函数是 cpu_cfs_quota_write_s64()
??? if (cft->write)
??????? return cft->write(cgrp, cft, file, buf, nbytes, ppos);
??? if (cft->write_u64 || cft->write_s64)
??????? return cgroup_write_X64(cgrp, cft, file, buf, nbytes, ppos);
??? if (cft->write_string)
??????? return cgroup_write_string(cgrp, cft, file, buf, nbytes, ppos);
??? ......
} ??
cpu_cfs_quota_write_s64函数源码如下：
static int cpu_cfs_quota_write_s64(struct cgroup *cgrp, struct cftype *cftype,
??????????????? s64 cfs_quota_us)
{
??? return tg_set_cfs_quota(cgroup_tg(cgrp), cfs_quota_us);
}
//设置进程组struct task_group的运行时间配额
int tg_set_cfs_quota(struct task_group *tg, long cfs_quota_us)
{
??? u64 quota, period;
??? //进程组的运行时间
??? period = ktime_to_ns(tg->cfs_bandwidth.period);
??? if (cfs_quota_us < 0)
??????? quota = RUNTIME_INF;
??? else
??????? quota = (u64)cfs_quota_us * NSEC_PER_USEC;
??? return tg_set_cfs_bandwidth(tg, period, quota);
}
static int tg_set_cfs_bandwidth(struct task_group *tg, u64 period, u64 quota)
{
??? struct cfs_bandwidth *cfs_b = &tg->cfs_bandwidth;
??? //进程组的运行周期和时间配额设置到进程组的struct task_group的cfs_bandwidth
??? cfs_b->period = ns_to_ktime(period);
??? cfs_b->quota = quota;
}
? ? 可以发现，根据传入的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%。
[root@localhost cpu]# mkdir test//创建cgroup目录
[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 进程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。什么意思？举个例子，如下：
[root@localhost cgroup]# sleep 999999&
[1] 64056 //新创建的进程PID是64056
[root@localhost cgroup]# cat cpu/tasks | grep 64056
64056
[root@localhost cgroup]# cat memory/tasks | grep 64056??
64056
[root@localhost cgroup]# cat blkio/tasks | grep 64056?????
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
static int cgroup_attach_task(struct cgroup *cgrp, struct task_struct *tsk,
????????????????? bool threadgroup)
{
??? int retval, i, group_size;
??? struct cgroup_subsys *ss, *failed_ss = NULL;
??? struct cgroupfs_root *root = cgrp->root;//代表cgroup子系统对应的文件系统
??? struct task_struct *leader = tsk;
??? struct task_and_cgroup *tc;
??? struct flex_array *group;
??? struct cgroup_taskset tset = { };
???
??? /*分配struct flex_array，顺带着分配内存，下边执行flex_array_put()向group指向的struct flex_array填充数据，然后在下边通过flex_array_get()从group指向的struct flex_array取出数据*/
??? group = flex_array_alloc(sizeof(*tc), group_size, GFP_KERNEL);
??? retval = flex_array_prealloc(group, 0, group_size, GFP_KERNEL);
??? do {
??????? struct task_and_cgroup ent;
??????? //ent.task保存待绑定进程的task_struct结构
??????? ent.task = tsk;
??????? /*找到要绑定的进程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吧*/
??????? ent.cgrp = task_cgroup_from_root(tsk, root);
??????? /*把struct task_and_cgroup ent保存到group指向的struct flex_array，ent包含了本次待绑定的进程task_struct和该进程之前绑定的struct cgroup*/
??????? retval = flex_array_put(group, i, &ent, GFP_ATOMIC);
??? }while_each_thread(leader, tsk);
???
??? /*tset.tc_array指向新分配的struct flex_array *group，group指向struct flex_array，flex_array里保存了struct task_and_cgroup ent，ent包含了本次待绑定的进程task_struct和该进程之前绑定的struct cgroup*/
??? tset.tc_array = group;
??? tset.tc_array_len = group_size;//group_size是本次要绑定进程的线程数
???
??? //group_size是本次要绑定进程的线程数，这是对本次绑定进程的每个线程依次处理
??? for (i = 0; i < group_size; i++) {
??????? /*从group指向的struct flex_array，找到并返回前边保存的struct task_and_cgroup给tc。之后tc包含了本次待绑定的进程/线程的task_struct和该进程/线程之前绑定的struct cgroup。说准确点，tc->cgrp是该进程/线程之前绑定的struct cgroup，tc->task是本次要绑定的进程/线程task结构*/
??????? tc = flex_array_get(group, i);
??????? /*找到已经存在的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三者关系的建立*/
??????? tc->cg = find_css_set(tc->task->cgroups, cgrp);
??? }
???
??? for (i = 0; i < group_size; i++) {
??????? /*从group指向的struct flex_array，找到并返回前边保存的struct task_and_cgroup给tc。tc->cgrp是该进程之前绑定的struct cgroup，tc->task是本次要绑定的进程task结构，tc->cg是本次绑定操作新分配的struct css_set*/
??????? tc = flex_array_get(group, i);
??????? /*前边建立了struct css_set、struct cg_cgroup_link、struct cgroup的关系，这是建立待绑定进程的struct task_struct结构与绑定的struct css_set的相互联系*/
??????? cgroup_task_migrate(tc->cgrp, tc->task, tc->cg);
??? }
??? for_each_subsys(root, ss) {
??????? /*调用该cgroup子系统struct cgroup_subsys的atach函数，cpu 子系统时是cpu_cgroup_attach()。进程绑定了新的cpu cgroup时，要从之前cpu cgroup清理干净，然后设置进程在新的进程组的关系*/
??????? if (ss->attach)
??????????? ss->attach(cgrp, &tset);
??? }
}
cgroup_attach_task函数的处理未免太过啰嗦，核心点只有几个
- 分配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取出这些信息。
- 循环执行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的关系。
- 循环执行执行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，三者相互的联系。
static struct css_set *find_css_set(
??? struct css_set *oldcg, struct cgroup *cgrp)
{
??? struct css_set *res;
??? struct cgroup_subsys_state *template[CGROUP_SUBSYS_COUNT];//template
???
??? /*如果找到已经存在的struct css_set，我觉得struct css_set *oldcg是存在的，这是试图找到与本次绑定的struct cgroup *cgrp的匹配的struct css_set，新创建的应该都不会成立吧*/
??? res = find_existing_css_set(oldcg, cgrp, template);
??? if (res)
??????? return res;
???
??? //分配struct css_set
??? res = kmalloc(sizeof(*res), GFP_KERNEL);
??? //分配root_count(应该是12)个struct cg_cgroup_link并添加到struct list_head tmp_cg_links链表，
??? allocate_cg_links(root_count, &tmp_cg_links) < 0);
??? //把struct cgroup_subsys_state *template[CGROUP_SUBSYS_COUNT]里所有的cgroup_subsys_state指针都复制到res->subsys[]数组
??? memcpy(res->subsys, template, sizeof(res->subsys));
???
??? /*遍历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*/
??? list_for_each_entry(link, &oldcg->cg_links, cg_link_list) {
??????? struct cgroup *c = link->cgrp;
????
??????? /*如果遍历到的老的css_set的cgroup与本次进程要绑定的cgorup属于同一个cgorup子系统，要替换成本次进程要绑定cgroup，即c = cgrp。然后下边建立本次进程要绑定cgroup和css_set的关系*/
??????? if (c->root == cgrp->root)
??????????? c = cgrp;
??????? /*对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三者联系*/
??????? link_css_set(&tmp_cg_links, res, c);
??? }
???
??? //以struct css_set *res所有struct cgroup_subsys_state *css[]所有的cgroup子系统cgroup_subsys_state指针累加值作为hash key
??? key = css_set_hash(res->subsys);
??? /*通过struct css_set *res的成员hlist把css_set添加到css_set_table这个hash树，key是css_set的struct cgroup_subsys_state *css[]所有cgroup_subsys_state指针累加值*/
??? hash_add(css_set_table, &res->hlist, key);
}
里边重点执行的是find_existing_css_set函数，
static struct css_set *find_existing_css_set(
??? struct css_set *oldcg,
??? struct cgroup *cgrp,
??? struct cgroup_subsys_state *template[])//template[]在这里
{
??? int i;
??? struct cgroupfs_root *root = cgrp->root;
??? struct css_set *cg;
??? unsigned long key;
??? /*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]*/
??? for (i = 0; i < CGROUP_SUBSYS_COUNT; i++) {
??????? /*这轮循环是本次进程要绑定的struct cgroup *cgrp对应的cgroup子系统，从本次进程要绑定的cgroup获取对应的cgroup_subsys_state
??????? if (root->subsys_mask & (1UL << i)) {
??????????? template[i] = cgrp->subsys[i];
??????? } else {
???????????? //从old cgroup获取对应的cgroup_subsys_state
??????????? template[i] = oldcg->subsys[i];
??????? }
??? }
??? /*hash key是template[]里所有的cgroup_subsys_state指针。此时template[]里的cgroup_subsys_state结合了老的oldcg和新的cgrp这两个cgroup的struct cgroup->subsys[]里所有的cgroup_subsys_state*/
??? key = css_set_hash(template);
??? //遍历所有的css_set_table hash链表上的css_set，
??? hash_for_each_possible(css_set_table, cg, hlist, key) {
??????? if (!compare_css_sets(cg, oldcg, cgrp, template))
?????????? ?continue;
??????? return cg;
??? }
??? return NULL;
}
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函数源码如下：
static bool compare_css_sets(struct css_set *cg,
???????????????? struct css_set *old_cg,
???????????????? struct cgroup *new_cgrp,
???????????????? struct cgroup_subsys_state *template[]
{
??? //l1和l2指向css_set的 struct list_head cg_links
??? l1 = &cg->cg_links;
??? l2 = &old_cg->cg_links;
??? while (1) {
??????? struct cg_cgroup_link *cgl1, *cgl2;
??????? struct cgroup *cg1, *cg2;
??????? //l1 = l1->next赋值后，l1才指向struct cg_cgroup_link的cg_link_list成员，然后list_entry()再找到struct cg_cgroup_link。l2同理
??????? l1 = l1->next;//下边list_entry()由l1指向的cg_link_list得到cg_cgroup_link
??????? l2 = l2->next;//下边list_entry()由l2指向的cg_link_list得到cg_cgroup_link
??????? BUG_ON(cg1->root != cg2->root);
??????? //由l1和l2指向的cg_link_list分别得到各自的cg_cgroup_link
??????? cgl1 = list_entry(l1, struct cg_cgroup_link, cg_link_list);
??????? cgl2 = list_entry(l2, struct cg_cgroup_link, cg_link_list);
??????? //再由cg_cgroup_link得到cgroup
??????? cg1 = cgl1->cgrp;
??????? cg2 = cgl2->cgrp;
??????? /*cg1->root == new_cgrp->root，说明本次循环遍历到的css_set_table链表上的css_set的cg_links链表上的cgroup和本次的new_cgrp属于同一个cgroup子系统.那就再看看这两个cgroup是否是cgroup目录(即if(cg1 != new_cgrp))，如果不是同一个cgroup，返回flase*/
??????? if (cg1->root == new_cgrp->root) {
??????????? if (cg1 != new_cgrp)
??????????????? return false;
??????? } else {
??????? //其他情况，css_set_table链表上的css_set的cg_links链表上的cgroup和old_cg的cg_links链表上的cgroup不相等，直接返回false
??????????? if (cg1 != cg2)
??????????????? return false;
??????? }
??? }
??? return true;
}
?? 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 进程绑定cgroup时，一定是从一个老的cgroup转移到新的cgroup，进程的cgroup信息继承父进程的，原始父进程绑定的有默认的cgroup。
- 2 两个进程绑定的cgroup层级、cgroup子系统、cgroup目录完全一致时，二者绑定的css_set是同一个。进程1绑定cpu/tasks和memory/tasks，进程2绑定cpu/tasks和memory/test/tasks，二者绑定的css_set不相同。
- 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()函数的如下代码完成
?????? list_for_each_entry(link, &oldcg->cg_links, cg_link_list)
?????? {?
?????????? //如果遍历到的老的css_set的cgroup与本次进程要绑定的cgorup属于同一个cgorup子系统，要替换成本次进程要绑定cgroup，然后下边建立本次进程要绑定cgroup5、css_set3的关系
?????????? if (c->root == cgrp->root)
?????????????? c = cgrp;
?????????? //设置进程task_struct结构与css_set的关系
?????????? link_css_set(&tmp_cg_links, res, c);
?????? }
???? 最后回到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
http://blog.chinaunix.net/uid-20543183-id-1930840.html
https://www.cnblogs.com/lisperl/archive/2012/04/18/2455027.html