为研究团队配置cgroups：cpu.cfs_quota_us与子组cpu.shares能否协同生效？

好问题！这两个cgroups CPU参数完全可以协同工作，你遇到的“shares仅在父组quota为-1且满负载时生效”的情况，本质是没搞清楚它们的作用边界和触发条件。咱们一步步理清楚：

1. 先搞懂两个参数的核心逻辑 #

• cpu.cfs_quota_us + cpu.cfs_period_us：这是硬限流规则，直接给当前cgroup划定了CPU时间的绝对上限。你的父组team配置是每100ms（cfs_period_us=100000）内最多使用400ms CPU时间，相当于锁定了最多4核的算力——不管系统整体负载如何，这个组的CPU总使用量绝不可能超过这个上限。
• cpu.shares：这是软优先级权重，它只在同级cgroups之间存在CPU资源竞争时才会生效。它不限制单个组的绝对使用量，而是当多个子组抢资源时，按照权重比例分配可用的CPU时间。默认权重是1024，你给user1设256、user2设768，相当于两者的资源分配比例是1:3。

2. 为什么你的场景里shares没生效？ #

你看到的现象是因为：当父组有cfs_quota_us限制时，子组的CPU总使用量被父组的配额框死了。如果子组的总CPU需求没有达到父组的quota上限（比如user1和user2的任务加起来只用了2核），那么子组之间根本不存在资源竞争——每个子组都能拿到自己需要的算力，cpu.shares自然不会触发生效。

只有当子组的总CPU需求超过父组的quota上限（也就是4核）时，子组之间才会开始抢父组那4核的配额，这时候cpu.shares的权重才会起作用：按照1:3的比例分配4核资源，也就是user1最多能分到1核左右的算力，user2能分到3核左右的算力。

3. 验证协同工作的实操方法 #

你可以按下面的步骤验证：

• 分别在team/user1和team/user2的cgroup下，启动足够多的满CPU负载任务（比如用yes > /dev/null &多开几个进程，直到每个子组的CPU需求都超过2核）。
• 用cgget -r cpu.stat team/user1和cgget -r cpu.stat team/user2查看子组的CPU使用统计，或者用top/htop观察进程的CPU占用。
• 你会看到两个子组的CPU总使用量加起来接近4核，且user1的CPU占比大概是user2的1/3，这就说明cfs_quota_us和cpu.shares在协同工作。

4. 额外注意点 #

• cpu.shares的比例是相对同级组的，比如如果后续再加一个user3设为512，那分配比例就变成256:768:512=1:3:2，父组的4核配额会按这个比例拆分。
• 父组的cfs_quota_us是子组的总天花板，子组的shares只是在这个天花板内分配竞争资源，两者是层级互补的关系，不是互斥的。

内容的提问来源于stack exchange，提问作者Naich An