Linux 组调度：从 task_group 到容器 CPU 限制
参考资料：kernel/sched/sched.h, kernel/sched/fair.c, kernel/sched/core.c, cgroup v2 docs
主题：组调度的数据结构、公平模型、带宽控制与运行时流程
组织方式：抽象对象; 模型; 运行
CFS 的公平调度解决的是"进程间"的公平——nice 0 的进程和 nice +5 的进程按权重分 CPU。但实际场景远比这复杂：容器 A 跑了 100 个进程，容器 B 只跑 2 个进程，如果只做进程级公平，A 会吃掉绝大部分 CPU。组调度就是把这个公平性从进程级提升到组级——先组间公平，再组内公平，递归到底层。
抽象对象
组调度引入的核心数据结构是 task_group，它把"组"这个概念具象化：一个组有自己的调度实体、自己的运行队列、自己的权重、自己的带宽控制。整个调度器从"task 直接挂在 rq 上"变成"task 挂在 group 的 cfs_rq 上，group 作为一个 sched_entity 挂在父级的 cfs_rq 上"，形成树形嵌套。
task_group — 组的容器
task_group 是组调度最外层的容器，定义在 kernel/sched/sched.h 中。每个组有四个 per-CPU 数组：se 是组在父级 cfs_rq 中的调度实体，cfs_rq 是组自己的运行队列。这保证了每个 CPU 有独立的调度状态，不需要跨 CPU 锁。
关注 se 和 cfs_rq 的关系——se 是组"在父级眼中"的样子，cfs_rq 是组"自己的内部"：
struct task_group {
struct task_group *parent; // 父组 -> 树形结构
struct list_head children; // 子组链表
struct sched_entity **se; // [NR_CPUS] 组在父级队列中的实体
struct cfs_rq **cfs_rq; // [NR_CPUS] 组自己的运行队列
unsigned long shares; // 组权重 (默认 1024 = nice 0)
struct cfs_bandwidth cfs_bandwidth; // 带宽控制 (quota/period)
};
shares 字段决定组在父级中的权重比例，默认 1024（对应 nice 0 的权重值）。通过 cgroup 设置 cpu.shares 就是写这个值。parent 指针让组之间形成树，root_task_group 是树的根。
sched_entity — 统一的调度单元
这是组调度最精妙的设计：无论是一个 task 还是一个 group，在调度器眼中都是 sched_entity。它们排在同一棵红黑树里，用 vruntime 排序。区分两者的唯一标志是 my_q 字段——如果是 task，my_q 为 NULL；如果是 group，my_q 指向组自己的 cfs_rq。
struct sched_entity {
struct cfs_rq *cfs_rq; // 当前所在的运行队列
struct cfs_rq *my_q; // 自己的队列 (group != NULL, task == NULL)
struct rb_node run_node; // 红黑树节点
u64 vruntime; // 虚拟运行时间
struct load_weight load; // 权重
unsigned long on_rq; // 是否在队列中
...
};
// 区分 task 和 group 的方式
if (se->my_q != NULL) {
// 这是 group, 选到它后要递归进入 my_q
} else {
// 这是 task, 可以直接运行
}
这意味着 pick_next_task_fair 在红黑树中选到最左 entity 后，不需要先判断"这是进程还是组"——只需要看 my_q：非空就递归进去，空就返回这个 task。
cfs_rq — 每组每 CPU 的运行队列
每个 task_group 有 NR_CPUS 个 cfs_rq 实例。root 的 cfs_rq 在 struct rq 中，子组的 cfs_rq 在task_group->cfs_rq[]中。同一个 CPU 上，root cfs_rq 挂载所有顶层 group 的 se，group 的 cfs_rq 挂载属于这个组的 task（或子 group）的 se。这种嵌套就是"层级公平"的物理基础。
cfs_bandwidth — 带宽控制
公平调度解决的是"谁该跑"的问题，带宽控制解决的是"最多跑多久"的问题。每个 task_group 有一个 cfs_bandwidth 结构（全局，不分 CPU），管理 quota、period、runtime 三个值：
struct cfs_bandwidth {
u64 quota; // 周期内可用时间 (ns), cpu.max 第一个值
u64 period; // 周期长度 (ns), cpu.max 第二个值
u64 runtime; // 剩余可用时间 (ns), 递减
u64 burst; // 允许突发借用的额度
s64 hierarchical_quota; // 嵌套组的配额上限
int throttle_count; // 被节流次数
...
};
quota 用完，cfs_rq 被标记为 throttled，从红黑树中移出——即使它的 task 的 vruntime 最低也不会被选中。这就是 cpu.max 的硬限制能力：shares 是软公平（影响分配比例），max 是硬上限（不可逾越）。
模型
有了前面的对象，现在看规则。组调度的核心模型有三条线：层级公平（公平如何递归传播）、vruntime 传播（组的 vruntime 怎么算）、带宽控制（quota 如何消耗和补充）。
层级公平 — 从 root 到叶子的递归分配
公平不是"所有 task 拉平"，而是"每一层公平"。root cfs_rq 把 CPU 按子组的 shares 比例分下去，每个子组再按自己的子 entity 的 shares 比例继续分。一个叶子 task 最终拿到的 CPU 比例，是从 root 到叶子路径上所有 share 比例的乘积。
看图中的具体数值：Group A shares=100，Group B shares=200，root 总 shares=300。所以 A 拿 100/300 = 33%，B 拿 200/300 = 67%。A 下有两个 task A1、A2，各 nice 0（等权），所以 A1 和 A2 各拿 A 的 50%，即 1/2 x 1/3 = 1/6 CPU。B 下面有个子组 B1 ，B1 的 task B1-1 和 B1-2 再按各自的 weight 分。
递归公平的数学表达——路径乘积：
// 叶子 task 获得的 CPU 比例
task_cpu_share = (my_weight / total_sibling_weight)
× parent_group_share
× grandparent_group_share
× ...
× root_level_share
// 示例: A1 的 CPU 比例
// A1 在 A 中的比例: 1/2 (与 A2 等权)
// A 在 root 中的比例: 1/3 (100/300)
// A1 = 1/2 × 1/3 = 1/6 CPU
// 示例: B1-1 (nice +5, weight=336) 的 CPU 比例
// B1-1 在 B1 中的比例: 336/(336+1024) ≈ 1/4
// B1 在 B 中的比例: 1/2 (与 B2 等权? 取决于 shares)
// B 在 root 中的比例: 2/3
// B1-1 ≈ 1/4 × 1/2 × 2/3 = 1/12 CPU
这里有个容易混淆的点：task 的权重由 nice 值决定（lookup table），group 的权重由 cpu.shares 直接写入。两者在同一个 cfs_rq 中排序时，都用 sched_entity->load.weight 参与 vruntime 计算。
vruntime 传播 — 组的 vruntime 怎么算
CFS 选 task 的依据是 vruntime——谁的最小谁先跑。组调度引入了一个问题：group entity 排在父级 cfs_rq 的红黑树里，但 group 本身不"跑"代码，它的 vruntime 从哪来？
答案：group entity 的 vruntime 由它子组 cfs_rq 的 min_vruntime 推导。当子组 cfs_rq 有 task 在跑，min_vruntime 会增长，这个增长会反映到 group entity 的 vruntime 上，让它在父级队列中"往前走"（vruntime 增大，优先级降低）。如果子组没有 task 在跑，group entity 的 vruntime 不动，在父级队列中保持不动，等其他组追上来。
// update_curr() in fair.c
static void update_curr(struct cfs_rq *cfs_rq)
{
u64 delta_exec = now - curr->exec_start;
curr->vruntime += delta_exec * NICE_0_LOAD / weight;
// 如果 curr 是 group, 它的 vruntime 变化
// 不会直接反映到父级 -- 父级看的是 min_vruntime
update_min_vruntime(cfs_rq);
// 如果 cfs_rq 属于某个 group:
// -> 它的 min_vruntime 变化
// -> 会通过 update_curr_nested 传播到父级 cfs_rq
// -> 父级用这个值更新 group entity 的 vruntime
}
这个传播机制保证了组调度的公平性不被破坏：如果 Group A 内只有一个 task 在狂跑，它的 vruntime 涨得快，Group A 的 se vruntime 也跟着涨，root 会选 Group B 的 se；反过来如果 Group A 内的 task 都阻塞了，Group A 的 se vruntime 不动，root 会继续选 Group A（它"亏欠"了 CPU 时间）。
带宽控制 — quota / period / throttle / unthrottle
带宽控制是组调度的第二条线：不管公平模型怎么分配，每个组的 CPU 消耗不超过 cpu.max 设定的上限。模型简单直白：period 是周期（默认 100ms），quota 是周期内可用时间（设 50ms 就是 0.5 核上限），runtime 是剩余可用时间，随运行递减。
看图 3 的时间轴。Period 1 开始时 runtime=quota=50ms，group 的 task 正常运行，每跑 1ms runtime 减 1。50ms 后 runtime 归零，cfs_rq 被标记 throttled=1，从红黑树中移出。Period 2 开始时 assign_cfs_runtime 补充 runtime（重新赋值 quota），throttled 的 cfs_rq 被 unthrottle，重新入队。
burst 是 5.6+ 引入的机制：允许组在本周期没用完 quota 时，把剩余部分"借"到下个周期，上限是 cpu.max.burst。这避免了"刚好差一点就被 throttle"的问题。但没用完的 burst 额度到了下个周期边界就清零——不能无限累积。
Cgroup v2 配置示例：
# /sys/fs/cgroup/groupA/cpu.max
# 格式: "$MAX $PERIOD" (微秒)
50000 100000 # 50ms / 100ms = 0.5 核上限
# 允许突发借用最多 15ms
echo 15000 > cpu.max.burst
# 设置软公平权重 (影响组间分配比例)
echo 100 > cpu.weight
# cpu.weight 范围: 1 ~ 10000 (默认 100)
# 注意: v2 用 cpu.weight 而非 v1 的 cpu.shares
这里有一个容易忽略的交互：shares（soft）和 max（hard）可以同时存在。shares 决定"在有富余 CPU 时该分多少"，max 决定"不管富不富余，最多多少"。一个 shares=10000（很高）但 max=0.5 核的组，在有富余 CPU 时会被公平模型分到很多，但 max 会把它截断在 0.5 核。
运行
对象和模型都有了，现在看运行时这些机制如何协同工作。三个关键流程：进程加入 cgroup 的迁移路径、pick_next_task 的递归下降、节流与恢复的时序。
进程加入 cgroup — sched_move_task
当用户把一个进程写进 cgroup.procs 时，内核调用 sched_move_task() 将 task 从当前 cfs_rq 移到新 group 的 cfs_rq。关键是 vruntime 的调整——task 的 vruntime 是相对当前队列的，换队列后需要按新队列的 min_vruntime 重新校准，否则 task 在新队列中的位置会错乱。
// 简化: sched_move_task -> __sched_move_task
static void __sched_move_task(struct task_struct *p, ...)
{
// 1. 从旧 cfs_rq dequeue
dequeue_task(rq, p, DEQUEUE_SAVE);
// 2. 切换 sched_entity 指向新 group
// se->cfs_rq = new_group->cfs_rq[cpu]
// se->vruntime 按新队列 min_vruntime 校准
p->se.vruntime -= old_cfs_rq->min_vruntime;
p->se.vruntime += new_cfs_rq->min_vruntime;
// 3. enqueue 到新 cfs_rq
enqueue_task(rq, p, ENQUEUE_RESTORE);
}
这个 vruntime 校准是组调度正确性的关键。如果 task 在旧队列的 vruntime 是 500，旧队列的 min_vruntime 是 400，那 task 的"相对 vruntime"是 500-400=100。换到新队列后，新队列 min_vruntime 是 800，task 的新 vruntime 应该是 800+100=900。这个调整保证了 task 在新队列中的相对位置不变。
pick_next_task_fair — 递归下降
选下一个 task 的流程体现了 sched_entity 统一抽象的威力。从 root cfs_rq 开始，选红黑树最左 entity。如果这个 entity 的 my_q 非空（是 group），递归进入 group 的 cfs_rq，继续选最左。直到 my_q 为空（是 task），返回。
右侧代码框展示的就是 pick_next_task_fair 的核心逻辑。注意那个 do-while 循环——它不是真正的函数递归（那会有栈开销），而是循环+指针切换：每次选到 group entity 就把 cfs_rq 指针切换到 group 的 my_q，继续下一轮循环。直到选到 my_q 为空的 entity（task），循环结束。
// pick_next_task_fair 核心逻辑 (简化)
struct cfs_rq *cfs_rq = &rq->cfs; // 从 root 开始
struct sched_entity *se;
do {
se = pick_next_entity(cfs_rq); // 红黑树最左节点
if (!se)
return NULL;
// 关键: group entity 被 throttle 后
// 它仍在树中, 但 pick 会跳过 throttled 的 cfs_rq
cfs_rq = se->my_q; // 如果是 group, 切换到子队列
} while (cfs_rq); // my_q == NULL -> 是 task, 退出
return task_of(se); // se 是 task entity, 取其 task_struct
注意图 4 底部的 throttle 路径说明：如果 group A 被节流了，它的 group entity 仍然在父级红黑树中，但 pick_next_entity 会跳过它——因为 throttled 的 cfs_rq 的 group entity 虽然在树里，但内核检查 cfs_rq->throttled 标志后会继续找下一个。这正是带宽控制"硬限制"的运行时体现。
配额内竞争 — 多任务共享有限 quota
前面讲了"组选 task"的递归下降和"组被 throttle"的时序，但漏了一个中间环节：当 CPU 选中一个组后，组内多个 task 如何瓜分有限的 quota？这是组调度最容易产生困惑的地方——一个组的 cpu.max 限制的是组整体的运行时间，不是单个 task 的。
先看单 CPU 的简单场景。一个组设了 cpu.max = "50000 100000"（0.5 核），组内有 3 个 CPU 密集型 task（T1、T2、T3，均 nice 0 等权），都在同一个 CPU 的 cfs_rq 上。CFS 在组内的 cfs_rq 里按 vruntime 公平选择，3 个 task 轮流跑——每个 task 拿到约 50/3 ≈ 16.7ms。50ms quota 耗尽后，cfs_rq 被标记 throttled，3 个 task 全部暂停，无论谁的 vruntime 更低。等到 100ms 周期边界，quota 补充为 50ms，cfs_rq unthrottle，3 个 task 继续按 vruntime 竞争。
多 CPU 场景更复杂，也更能体现组调度的精妙。一个组设了 cpu.max = "200000 100000"（2 核），但组内有 6 个 CPU 密集型 task 分布在 3 个 CPU 上。全局 quota 是 200ms，但每个 CPU 有自己的 cfs_rq，各自独立调度。内核如何保证 3 个 cfs_rq 加起来不超过 200ms？
Image答案是一个两级分配机制。全局的 cfs_bandwidth.runtime 是池子，每个 CPU 的 cfs_rq 有自己的 runtime_remaining。cfs_rq 消耗本地 runtime，用完后向全局池申请一个 slice（sched_cfs_bandwidth_slice，默认 5ms）。全局池的 200ms 被各个 CPU 轮流"领取"，直到耗尽。全局 runtime 归零后，所有 CPU 上该组的 cfs_rq 同时被 throttle。
// sched_cfs_bandwidth_slice 默认 5ms (sysctl 可调)
// 每个 cfs_rq 本地持有一个 slice 的 runtime
// 用完后向全局池申请新的 slice
// assign_cfs_runtime (简化): 从全局池分发一个 slice 到本地 cfs_rq
static void assign_cfs_runtime(struct cfs_rq *cfs_rq)
{
struct cfs_bandwidth *cfs_b = &cfs_rq->tg->cfs_bandwidth;
// 从全局池取出一个 slice (默认 5ms)
u64 amount = min(sched_cfs_bandwidth_slice, cfs_b->runtime);
cfs_b->runtime -= amount; // 全局池扣除
cfs_rq->runtime_remaining += amount; // 本地 cfs_rq 补充
}
// account_cfs_rq_runtime (简化): 每次 tick 检查本地额度
static void account_cfs_rq_runtime(struct cfs_rq *cfs_rq, u64 delta_exec)
{
cfs_rq->runtime_remaining -= delta_exec;
if (cfs_rq->runtime_remaining < 0) {
// 本地 slice 用完, 向全局池申请新的
assign_cfs_runtime(cfs_rq);
if (cfs_rq->runtime_remaining < 0) {
// 全局池也空了 -> throttle
throttle_cfs_rq(cfs_rq);
}
}
}
这个 slice 机制带来一个重要推论：cpu.max 限制的是组整体的吞吐量，不限制组内 task 的数量。6 个 task 在 2 核 quota 下，每个 task 的平均吞吐量是 2/6 = 0.33 核。CFS 在每个 cfs_rq 内部保证 task 间的公平，cfs_bandwidth 在 cfs_rq 之间保证总量的硬限制。两层机制叠加，实现了"组间有上限、组内有公平"。
实际效果是：3 个 CPU 上的 task 各自运行，每 5ms 检查一次本地 runtime。当某个 CPU 的本地 5ms 用完，向全局池再领 5ms。200ms 总量大约支撑 40 个 slice 的领取，分摊到 3 个 CPU 上每个 CPU 约 13 个 slice ≈ 67ms 的实际运行时间。这就是 2 核 quota 在 3 CPU 上的实际效果——不是每个 CPU 都能跑满，而是总量控制在 200ms。
节流与恢复 — 从 throttle 到 unthrottle
throttle 的触发点在 update_curr() 里——每次更新 task 的运行时间后，检查 cfs_bandwidth 的 runtime 是否耗尽。耗尽了就调 throttle_cfs_rq() 把该 cfs_rq 从父级红黑树移出，标记 throttled=1。
// throttle_cfs_rq (简化)
static void throttle_cfs_rq(struct cfs_rq *cfs_rq)
{
// 1. 从父级红黑树中移出 group entity
__dequeue_entity(&cfs_rq->tg->se[cpu]->cfs_rq->rb_root,
cfs_rq->tg->se[cpu]);
// 2. 标记 throttled
cfs_rq->throttled = 1;
// 3. 计数
cfs_rq->tg->cfs_bandwidth.throttle_count++;
}
// unthrottle_cfs_rq (简化)
static void unthrottle_cfs_rq(struct cfs_rq *cfs_rq)
{
cfs_rq->throttled = 0;
// 重新 enqueue group entity 到父级红黑树
__enqueue_entity(&cfs_rq->tg->se[cpu]->cfs_rq->rb_root,
cfs_rq->tg->se[cpu]);
}
unthrottle 的触发时机在 period 边界——cfs_bandwidth 有一个高精度定时器 slack_timer，在 period 到期时回调 assign_cfs_runtime()：把 runtime 重置为 quota（减去 burst 已用），然后遍历所有被节流的 cfs_rq 逐个 unthrottle。
实际场景 — 容器 CPU 限制
组调度最直接的应用就是容器 CPU 限制。Docker 的 --cpus=2 本质上是设 cpu.max = "200000 100000"（200ms/100ms = 2 核）。--cpu-shares=512 设 cpu.weight=512。两者的区别：
| | |
|---|
cpu.weight | | |
cpu.max | | quota 用完就 throttle，不管系统是否空闲 |
cpu.max.burst | | |
一个常见误解：设了 --cpus=2 后容器是否"独占" 2 核？不是。cpu.max 只限制上限（最多 2 核），不保证下限。如果宿主机有 4 核且全部空闲，设了 max=2 核的容器可以用满 2 核；如果宿主机超卖，这个容器会被 throttle 到 2 核以内，但拿不到额外的。要同时保证下限，需要配 cpuset 绑定或 CFS quota + RT 调度。
排查路径
容器 CPU 被限制时的排查路径：
# 1. 检查是否被 throttle
cat /sys/fs/cgroup/groupA/cpu.stat
# 输出: nr_periods, nr_throttled, throttled_time
# nr_throttled > 0 说明 max 在生效
# 2. 查看 CPU 限制
cat /sys/fs/cgroup/groupA/cpu.max
# 50000 100000 => 0.5 核上限
# 3. 查看权重
cat /sys/fs/cgroup/groupA/cpu.weight
# 100 (默认值)
# 4. 如果 nr_throttled 很高, 说明:
# - 要么 quota 设太低
# - 要么 group 内 task 确实需要更多 CPU
# - 要么有 CPU 密集型 task 把 quota 消耗殆尽
# 5. 调整方案:
# - 提高 quota: echo "80000 100000" > cpu.max (0.8 核)
# - 加 burst: echo 20000 > cpu.max.burst
# - 调 weight: echo 200 > cpu.weight (竞争时拿更多)
总结
组调度的设计哲学可以浓缩成一句话：把公平性从进程级提升到组级，用统一的 sched_entity 抽象抹平 task 和 group 的差异。task_group 是容器，sched_entity 是统一接口，cfs_rq 是每层每 CPU 的运行队列，cfs_bandwidth 是硬限制。
三条线串起来：
层级公平：shares 从 root 递归分配到叶子 task，路径上的比例相乘就是最终份额。公平不是拉平，是逐层公平。
vruntime 传播：group 的 vruntime 由子组 cfs_rq 的 min_vruntime 推导，让组间公平不被打破。组内 task 跑多了，组的 se vruntime 涨快，别的组就优先。
带宽控制：quota/period/throttle/unthrottle 的周期循环。shares 是软公平，max 是硬上限，两者独立但可共存。
容器的 --cpus 和 --cpu-shares 最终都落到这两条线上——一个写 cfs_bandwidth.quota，一个写 task_group.shares。理解了这两个值的含义和交互，容器 CPU 行为就不再黑盒。
