4. cgroup v2 CPU 控制器：cpu.weight、cpu.max、cpu.stat 接口变更与优势

cgroup v2 对 CPU 控制器进行了根本性的重构，摒弃了 v1 中多个独立子系统（cpu、cpuacct）并存的复杂模型，转而采用统一的 cpu 控制器。这一变革带来了更清晰的层次结构、更直观的权重分配机制以及更强大的带宽控制能力。本节将深入剖析 v2 核心接口的设计哲学与操作优势。

4.1 核心接口变更：从 shares/quota 到 weight/max

cgroup v2 将 v1 中的 cpu.shares、cpu.cfs_quota_us、cpu.cfs_period_us 等分散文件，整合为两个核心文件：cpu.weight 和 cpu.max。这种设计不仅减少了文件数量，更在语义上实现了统一。

4.2 cpu.weight：细粒度权重分配

cpu.weight 是 cgroup v2 中实现 CPU 时间相对分配的核心参数。与 v1 的 cpu.shares 相比，v2 的权重模型在竞争激烈时表现更平滑，且对 CFS 调度器的负载均衡算法进行了优化。

• 范围与默认值： 取值范围为 1（最低优先级）到 10000（最高优先级），默认值为 100。这个范围设计使得在容器编排平台（如 Kubernetes）中，可以轻松地将 QoS 等级映射为具体的 weight 值。
• 竞争模型： 当多个 cgroup 同时争用 CPU 时，调度器按 weight / 所有活跃子组 weight 之和 的比例分配时间片。空闲 CPU 不会被浪费，而是按比例分配给有需求的组。
• 层级行为： 子 cgroup 的 weight 仅在兄弟节点之间生效。父组的 weight 决定了整个子树在全局中的份额，而子组之间的竞争则基于各自的 weight 值。

# 创建两个竞争组
mkdir -p /sys/fs/cgroup/cpu/container-A /sys/fs/cgroup/cpu/container-B

# 设置权重：A 获得 2/3，B 获得 1/3
echo 200 > /sys/fs/cgroup/cpu/container-A/cpu.weight
echo 100 > /sys/fs/cgroup/cpu/container-B/cpu.weight

# 启动两个 CPU 密集型进程并加入对应组
# 预期：container-A 中的进程将获得约 2 倍于 container-B 的 CPU 时间

4.3 cpu.max：统一的带宽上限控制

cpu.max 文件取代了 v1 中 cpu.cfs_quota_us 和 cpu.cfs_period_us 的组合，以 $MAX $PERIOD 的格式提供带宽限制。其核心优势在于语法简洁、支持动态调整，并且引入了 max 关键字来明确表示“无限制”。

# 限制容器最多使用 2 个 CPU 核心（周期 100ms）
echo "200000 100000" > /sys/fs/cgroup/cpu/container-A/cpu.max

# 移除限制，允许使用所有空闲 CPU
echo "max 100000" > /sys/fs/cgroup/cpu/container-A/cpu.max

4.4 cpu.stat：统一且丰富的统计视图

cgroup v2 的 cpu.stat 文件整合了 v1 中分散在 cpu.stat 和 cpuacct.stat 中的信息，并新增了调度延迟和压力指标，为运维监控提供了更全面的数据源。

# 查看某个容器的 CPU 统计
cat /sys/fs/cgroup/cpu/container-A/cpu.stat

# 输出示例：
# usage_usec 123456789          # 总 CPU 使用时间（微秒）
# user_usec 100000000           # 用户态使用时间
# system_usec 23456789          # 内核态使用时间
# nr_periods 500                # 经过的周期数（仅当设置了 cpu.max 时）
# nr_throttled 10               # 被限流的周期数
# throttled_usec 5000000        # 被限流的总时间（微秒）
# nr_bursts 0                   # 突发使用次数（v6.1+ 新增）
# burst_usec 0                  # 突发使用总时间（v6.1+ 新增）

4.5 架构优势对比：v1 与 v2 的 CPU 控制路径

下面的 SVG 图展示了 cgroup v1 和 v2 在 CPU 控制路径上的架构差异。v2 通过统一的 cpu 控制器，简化了数据流和决策路径，减少了内核态的开销。

4.6 容器化环境中的实际优势

在 Kubernetes 等容器编排平台中，cgroup v2 的 CPU 控制器带来了以下可量化的改进：

1. 配置原子性： 写入 cpu.max 是一次系统调用，避免了 v1 中先后写入 quota 和 period 可能导致的中间状态（例如 quota 已更新但 period 未更新，导致调度器读到不一致的配置）。
2. 统计一致性： cpu.stat 文件中的 usage_usec 等字段，在读取时保证是该 cgroup 及其所有子 cgroup 的瞬时快照，无需像 v1 那样从多个文件拼凑数据。
3. 层级管理简化： 在 v2 中，Pod 级别的 QoS 类（Guaranteed、Burstable、BestEffort）可以直接映射为 cpu.weight 值，而无需像 v1 那样通过复杂的 shares 计算和额外的 cpu.rt_runtime_us 配置。
4. 压力感知调度： v2 的 cpu.stat 为后续的 PSI（Pressure Stall Information）提供了基础数据，使得调度器可以感知 CPU 压力，从而做出更优的负载均衡决策。