作者：姜亚华（@二如公子 ），《精通 Linux 内核——智能设备开发核心技术》的作者，一直从事与 Linux 内核和 Linux 编程相关的工作，研究内核代码十多年，对多数模块的细节如数家珍。曾负责华为手机 Touch、Sensor 的驱动和软件优化（包括 Mate、荣耀等系列），以及 Intel 安卓平台 Camera 和 Sensor 的驱动开发（包括 Baytrail、Cherrytrail、Cherrytrail CR、Sofia 等）。现负责 DMA、Interrupt、Semaphore 等模块的优化与验证（包括 Vega、Navi 系列和多款 APU 产品）。
往期回顾：点击查看
一、cgroup 的使用
测试环境版本与之前一致：
| Ubuntu (lsb_release -a) |
Distributor ID: Ubuntu Description: Ubuntu 19.10 Release: 19.10 |
| Linux (uname -a) |
Linux yahua 5.5.5 #1 SMP … x86_64 x86_64 x86_64 GNU/Linux |
在前面的文章中，我们探讨了容器底层 cgroup 的数据结构与代码实现，本期是 cgroup 系列的最后一篇文章，我们将继续探讨在 mount 成功后，我们如何使用 cgroup 来实现进程限制。
在 mount 成功后，cgroup_root 已经存在了，也就是说 cgroup 层级结构已经搭建好了，接下来我们就可以使用 cgroup 了。
1. cgroup 的 mkdir
mkdir 比 mount 的过程稍简单，由 cgroup_mkdir 函数实现，主要逻辑如下：
int cgroup_mkdir(struct kernfs_node *parent_kn, const char *name, umode_t mode)
{
struct cgroup *parent, *cgrp;
parent = cgroup_kn_lock_live(parent_kn, false); //1
cgrp = cgroup_create(parent, name, mode); //2
ret = cgroup_kn_set_ugid(cgrp->kn);
ret = css_populate_dir(&cgrp->self); //3
ret = cgroup_apply_control_enable(cgrp);
kernfs_activate(cgrp->kn);
ret = 0;
return ret;
｝
第 1 步，获得父目录对应的 cgroup。无论是 cgroup_setup_root 还是接下来要说的cgroup_create，在创建文件的时候都将 cgroup 赋值给了 kernfs_node 的 priv。所以这里其实就是返回 parent_kn->priv 字段，不过要经过参数检查。
第 2 步，调用 cgroup_create：创建 cgroup，调用 kernfs_create_dir 创建目录，建立新cgroup 和父 cgroup 的父子关系。
第 3 步，和 mount 的时候一样，css_populate_dir 和 cgroup_apply_control_enable 会为我们创建 cftype 对应的文件，不过有两点区别：
首先，带 CFTYPE_ONLY_ON_ROOT 标志的 cftype 不会出现在这里，比如cgroup.sane_behavior 和 release_agent。
其次，mount 的时候，新 cgroup_root.cgrp 复用了原 cgroup_root.cgrp 相关的css（rebind_subsystems，第二篇），这里新建了一个 cgroup，cgroup_apply_control_enable 需要为我们创建新的 css（ss->css_alloc(parent_css)）并建立 cgroup 和 ss 的多对多关系（init_and_link_css和online_css）。
mount 的时候，cpuset 的 css_alloc 返回的是全局的 top_cpuset.css，这里创建一个新的 cpuset 对象并初始化，如下：
struct cgroup_subsys_state *
cpuset_css_alloc(struct cgroup_subsys_state *parent_css)
{
struct cpuset *cs;
if (!parent_css) //mount的时候，返回top_cpuset.css
return &top_cpuset.css;
cs = kzalloc(sizeof(*cs), GFP_KERNEL);
alloc_cpumasks(cs, NULL); //#1
set_bit(CS_SCHED_LOAD_BALANCE, &cs->flags);
nodes_clear(cs->mems_allowed);
nodes_clear(cs->effective_mems); //#2
fmeter_init(&cs->fmeter);
cs->relax_domain_level = -1;
return &cs->css；
｝
注意标号 #1 和 #2，新 cs 的 cpus_allowed 和 mems_allowed 都被清零，此时读取cpuset.cpus 和 cpuset.mems 也是没有内容的，也就是说对 cpu 和 memory 的限制并不能从父目录继承，在使用前必须正确设置它们。
2. 限制资源
我们在第一篇的例子中通过 echo 0-2 > cpuset.cpus 和 echo 0 > cpuset.mems 限制 /cpuset0 管理的进程使用的 cpu 和 memory node，以 cpuset.cpus 为例，它的 cftype 如下：
{
.name = "cpus",
.seq_show = cpuset_common_seq_show,
.write = cpuset_write_resmask,
.max_write_len = (100U + 6 * NR_CPUS),
.private = FILE_CPULIST,
},
最终调用的是 cpuset_write_resmask，后者调用 update_cpumask。
update_cpumask 的目的是更新我们在 mkdir 时创建的 cpuset（cpuset_css_alloc），当然了，之前已经配置过的 cpuset 重新配置也可以。我们关心以下几点：
- 不能更改top_cpuset的设置，这就是第一篇的课堂作业第一题的答案。
- 目标cpuset的资源必须是父目录cpuset的子集，而且是子目录cpuset的超集（由validate_change函数实现），这是课堂作业第二题的答案。
- 配置的资源最终更新cpuset的cpus_allowed字段。
可以看到，类似课堂作业中描述的类似限制，是需要 ss 自行实现的，cgroup 本身并不保证这点，尝试开发新的 ss 的时候需要注意这点。
3. 管理进程
我们在例子中将进程号写到 tasks 文件（echo $$ > tasks），以限制进程只能使用 /cpuset0 配置的 cpu 和 memory node。实际上，写 cgroup.procs 文件也是可以的。它们的 cftype 文件定义如下：
{
.name = "tasks",
.seq_start = cgroup_pidlist_start,
.seq_next = cgroup_pidlist_next,
.seq_stop = cgroup_pidlist_stop,
.seq_show = cgroup_pidlist_show,
.private = CGROUP_FILE_TASKS,
.write = cgroup1_tasks_write,
},
{
.name = "cgroup.procs",
.seq_start = cgroup_pidlist_start,
.seq_next = cgroup_pidlist_next,
.seq_stop = cgroup_pidlist_stop,
.seq_show = cgroup_pidlist_show,
.private = CGROUP_FILE_PROCS,
.write = cgroup1_procs_write,
},
两个文件的 write 分别是 cgroup1_tasks_write 和 cgroup1_procs_write，它们都是调用__cgroup1_procs_write 实现的，区别仅在于最后一个参数 threadgroup 不同，前者为false，后者为 true。看名字就知道，为 false 的情况下，仅作用于目标进程（线程），为 true 的情况下，作用于线程组。
这里对线程组稍作说明。线程组是属于同一个进程的线程的集合，同一个线程组的线程，它们的 task_struct 都通过 thread_group 字段链接到同一个链表中，链表的头为线程组领导进程的 task_struct 的 thread_group 字段，可以据此来遍历线程组。
__cgroup1_procs_write 可以分成以下 3 步：
第1步，调用 cgroup_kn_lock_live 获得文件所在的目录的 cgroup，实际上就是kernfs_node->parent->priv，kernfs_node->parent 是文件所在目录的 kernfs_node，priv 就是目标 cgroup。
第2步，调用 cgroup_procs_write_start 根据用户空间传递的进程 id 参数获得目标进程的 task_struct，threadgroup 为 true 的情况下，获得的是线程组领导进程的task_struct。
第3步，调用 cgroup_attach_task 将进程 attach 到（依附于或者连接）cgroup。
cgroup 和 ss 之间是对等的关系，使用的是 bind，称之为绑定；进程和 cgroup 之间并不是对等的关系，使用的是 attach，称之为依附。
请注意，我们举例中仅涉及 cpuset，并不意味着某个进程只与 cpuset 有关，进程和cgroup 的关系是通过 css_set 实现的，也就是说是一组 cgroup。我们没有更改其他cgroup 层级结构的配置，这意味着进程关联的是它们的 cgroup_root，并不是没有关联。
先不论进程被创建后，“辗转”了几组cgroup，进程被创建时就已经attach cgroup了。
进程创建的过程在书里已经详细地分析过了，这里仅讨论与cgroup相关的部分。
首先被调用的是cgroup_fork，如下：
void cgroup_fork(struct task_struct *child)
{
RCU_INIT_POINTER(child->cgroups, &init_css_set);
INIT_LIST_HEAD(&child->cg_list);
}
直接指向了 init_css_set，不过这有可能是暂时的。child->cg_list 是空的，说明新进程还没有 attach 到任何 cgroup。
其次是 cgroup_can_fork，它调用 ss->can_fork，由 ss 判断是否可以创建新进程，如果答案是否，整个 fork 会失败。
最后是 cgroup_post_fork，做最后的调整，主要逻辑如下：
void cgroup_post_fork(struct task_struct *child)
{
struct cgroup_subsys *ss;
struct css_set *cset;
if (likely(child->pid)) {
WARN_ON_ONCE(!list_empty(&child->cg_list));
cset = task_css_set(current); /* current is @child's parent */
get_css_set(cset);
cset->nr_tasks++;
css_set_move_task(child, NULL, cset, false);
}
do_each_subsys_mask(ss, i, have_fork_callback) {
ss->fork(child);
} while_each_subsys_mask();
}
首先，current 是新进程 child 的父进程，先获得父进程的 css，然后调用css_set_move_task 将新进程转移到该 css 上。css_set_move_task 的第二个参数是原css，这里是 NULL 是因为还没有 attach 到任何 cgroup（css_set）上。css_set_move_task 会将 child->cg_list 插入 css->tasks 链表上，child->cg_list 不再为空。
也就是说，新进程在创建时会被 attach 到与父进程同一组 cgroup 上。
其次，如果 ss 定义了 fork，调用 ss->fork，以 cpuset 为例，它会为新进程复制父进程的设置，如下：
void cpuset_fork(struct task_struct *task)
{
if (task_css_is_root(task, cpuset_cgrp_id))
return;
set_cpus_allowed_ptr(task, current->cpus_ptr);
task->mems_allowed = current->mems_allowed;
}
回顾下第一篇的例子，我们在 cpuset 下创建的 cpuset0 目录，配置资源，管理进程。修改下，在 cpuset 下再创建一个 cpuset1 目录，进程先 attach 到 /cpuset0，然后migrate 到 /cpuset1上，以此为例分析 migrate 的过程：
love_cc@yahua:/sys/fs/cgroup/cpuset$ sudo mkdir cpuset0
love_cc@yahua:/sys/fs/cgroup/cpuset$ sudo mkdir cpuset1
love_cc@yahua:/sys/fs/cgroup/cpuset$ cd cpuset0/
root@yahua:/sys/fs/cgroup/cpuset/cpuset0# echo 0-2 > cpuset.cpus
root@yahua:/sys/fs/cgroup/cpuset/cpuset0# echo 0 > cpuset.mems
root@yahua:/sys/fs/cgroup/cpuset/cpuset0# echo $$ > tasks
root@yahua:/sys/fs/cgroup/cpuset/cpuset0# cat tasks
2682
2690
root@yahua:/sys/fs/cgroup/cpuset/cpuset0# cd ../cpuset1/
root@yahua:/sys/fs/cgroup/cpuset/cpuset1# echo 0-1 > cpuset.cpus
root@yahua:/sys/fs/cgroup/cpuset/cpuset1# echo 0 > cpuset.mems
root@yahua:/sys/fs/cgroup/cpuset/cpuset1# echo $$ > tasks
root@yahua:/sys/fs/cgroup/cpuset/cpuset1# cat tasks
2682
2713
root@yahua:/sys/fs/cgroup/cpuset/cpuset1# cat ../cpuset0/tasks
#没有省略内容，空的
继续讨论之前，先理一下目前的状况，我们在 __cgroup1_procs_write 函数的第 3 步cgroup_attach_task，之前的两步我们已经获得了目标 cgroup（也就是 /cpuset1）和进程的 task_struct。
cgroup_attach_task 的目的是将进程 attach 到目标 cgroup，逻辑上至少包括进程和原group detach 和进程和目标 cgroup attach 两部分。三个要素，src、dst 和 migrate，正好对应三个函数 cgroup_migrate_add_src、cgroup_migrate_prepare_dst 和cgroup_migrate。
首先被调用的是 cgroup_migrate_add_src，threadgroup 为 true 的情况下，对线程组的每个线程调用一次，否则调用一次即可，它的主要逻辑如下：
void cgroup_migrate_add_src(struct css_set *src_cset,
struct cgroup *dst_cgrp,
struct cgroup_mgctx *mgctx)
{
struct cgroup *src_cgrp;
src_cgrp = cset_cgroup_from_root(src_cset, dst_cgrp->root);
src_cset->mg_src_cgrp = src_cgrp;
src_cset->mg_dst_cgrp = dst_cgrp;
get_css_set(src_cset);
list_add_tail(&src_cset->mg_preload_node, &mgctx->preloaded_src_csets);
第一个参数 src_cset 表示进程原来的 css_set，也就是 task_struct 的 cgroups 字段。
首先要做的就是在目标 cgroup（dst_cgrp，也就是 /cpuset1）所属的 cgroup_root 中找到原 cgroup（src_cgrp，也就是 /cpuset0），它跟目标 cgroup 属于同一个cgroup_root，查找的过程就变成找到 src_cset 对应的某个 cgroup，它的 root 字段与dst_cgrp->root 相等，如下：
list_for_each_entry(link, &cset->cgrp_links, cgrp_link) {
struct cgroup *c = link->cgrp;
if (c->root == root) {
res = c; //res就是我们要找的
break;
}
}
提醒下，任何一个 cgroup 层级结构中，进程只能关联其中一个 cgroup，所以与 /cpuset1 属于同一个 cgroup_root 的只能是 /cpuset0 。
另外，我们分析的只是一种情况，前面说的 Ubuntu mount cpuset 的时候，进程从默认的层级结构迁移到 cpuset 上，原 cgroup 和目标 cgroup 实际上属于不同的cgroup_root，返回的是目标 cgroup_root 的 cgrp。
cgroup_migrate_add_src 的第三个参数 mgctx 是 cgroup_attach_task 的局部变量，函数结束前将 src_cset 插入到 mgctx->preloaded_src_csets 等待后续处理。
cgroup_migrate_prepare_dst 遍历 mgctx->preloaded_src_csets上的 src_cset，根据src_cset 和 src_cset->mg_dst_cgrp 查找当前已经存在的 css_set 是否有某个 css_set与期望一致，没有则创建新的 css_set 并赋以期望值。
期望，一致，两方面。
怎么描述我们的期望呢，进程只是从 /cpuset0 移到 /cpuset1 上，关联的其他 cgroup 层级结构的 cgroup 并没有变化，所以以原 css_set 作为模板，调整 cpuset 层级结构上的css 即可，实际的代码也大致如此，如下：
for_each_subsys(ss, i) {
if (root->subsys_mask & (1UL << i)) {
template[i] = cgroup_e_css_by_mask(cgrp, ss);
} else {
template[i] = old_cset->subsys[i];
}
}
root 就是发生变动的层级结构的 cgroup_root，在我们的例子中就是 cpuset，至于cgroup_e_css_by_mask，这里的 e 是 effective，不考虑 cgroup v2 的情况下，也可以理解为 cgroup_css(cgrp, ss)，也就是 /cpuset1 和 cpuset ss 对应的 css 。
某个 css_set（简称 cset）与我们的期望一致，需要满足以下两点。
首先，cset->subsys 与 template 一致，其实还是与 v2 有关。
其次，cset 的 css（cgrp_links字段）中，属于当前 cgroup_root 的，关联的 cgroup 是目标值，也就是 /cpuset1；不属于当前 cgroup_root 的，与 old_cset 关联的 cgroup 相等。
css_set 的 subsys 和 cgrp_links 都表示它关联的 css，二者有什么区别？subsys 在css_set 被创建后不会改变，cgrp_links 可以动态调整。比如 cgroup_setup_root 中调用的 link_css_set，修改的只是 cgrp_links。
如果找不到一致的 css_set，创建一个新的，按照要求的两点给它赋值。
接下来就是 cgroup_migrate 了，它的实现代码较多，但逻辑都是直来直去，我们就不直接分析代码了，主要分以下几步：
- 调用 cgroup_migrate_add_task 将需要迁移的进程放入 mgctx->tset，然后调用cgroup_migrate_execute 函数，实际的 migrate 过程由它完成。
- 回调有变动的 ss 的 ss->can_attach 函数，判断是否合法。
- 遍历需要 migrate 的进程，调用 css_set_move_task(task, from_cset, to_cset, true)，进程的 css_set 得到更新。
- 回调有变动的 ss 的 ss->attach，migrate 正式生效。
- cpuset 的 attach 由 cpuset_attach 函数实现，核心逻辑如下：
cgroup_taskset_for_each(task, css, tset) {
WARN_ON_ONCE(set_cpus_allowed_ptr(task, cpus_attach));
cpuset_change_task_nodemask(task, &cpuset_attach_nodemask_to);
cpuset_update_task_spread_flag(cs, task);
}
遍历进程，使 cpu 和 memory node 的限制生效。
我们分析的限制进程使用 cpu 由 set_cpus_allowed_ptr 调用 __set_cpus_allowed_ptr 实现，主要逻辑如下：
int __set_cpus_allowed_ptr(struct task_struct *p,
const struct cpumask *new_mask, bool check)
{
const struct cpumask *cpu_valid_mask = cpu_active_mask;
unsigned int dest_cpu;
struct rq_flags rf;
struct rq *rq;
rq = task_rq_lock(p, &rf);
update_rq_clock(rq);
if (cpumask_equal(p->cpus_ptr, new_mask)) //1
goto out;
dest_cpu = cpumask_any_and(cpu_valid_mask, new_mask); //2
if (dest_cpu >= nr_cpu_ids) {
ret = -EINVAL;
goto out;
}
do_set_cpus_allowed(p, new_mask); //3
if (cpumask_test_cpu(task_cpu(p), new_mask)) //4
goto out;
if (task_running(rq, p) || p->state == TASK_WAKING) { //5
struct migration_arg arg = { p, dest_cpu };
task_rq_unlock(rq, p, &rf);
stop_one_cpu(cpu_of(rq), migration_cpu_stop, &arg);
return 0;
} else if (task_on_rq_queued(p)) {
rq = move_queued_task(rq, &rf, p, dest_cpu);
}
out:
task_rq_unlock(rq, p, &rf);
return ret;
}
满屏都是进程调度章节的内容，在此解释如下：
第1步，如果没有改变，直接退出。
第2步，指定的资源是否合法，如果不合法，返回错误。
第3步，do_set_cpus_allowed 会调用 p->sched_class->set_cpus_allowed 由具体的调度类实现，调度类一般会更新 task_struct 的 cpus_mask 字段。
第4步，进程当前所在的 cpu 是否在限制范围内，如果在，不需要额外处理。
第5步，进程被限制，不能使用当前所在的 cpu，如果正在运行则停止并 migrate，如果正在等待执行，移到其他 cpu 上。
cgroup v1 的讨论差不多了，绝大部分篇幅集中讨论最常用的操作，但实际上还不完整，其余操作大家可以自行继续当前的思路阅读。
往期回顾
容器底层 cgroup 如何实现资源分组？
容器底层 cgroup 的代码实现分析
