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
- 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
Linux cgroup机制分析之框架分析-xgr180-ChinaUnix博客
https://www.cnblogs.com/lisperl/archive/2012/04/18/2455027.html