Redhat 有一个很棒的博客文章描述 CPUShares，但它假设进程驻留在叶子CGroups，并没有讨论如何计算驻留在分支CGroups。
例如：每个进程的 CPU 使用率是多少？
- CGroup A（CPU 份额：1024）
- 进程 1（以最大 CPU 速度旋转）
- CGroup B（CPU 份额：512）
- 进程 2（以最大 CPU 速度旋转）
- CGroup C（CPU 份额：256）
- 进程 3（以最大 CPU 速度旋转）
- CGroup D（CPU 份额：128）
- 进程 4（以最大 CPU 速度旋转）
| 过程 | CPU使用率 （％） |
|---|---|
| 流程 1 | ??? |
| 流程 2 | ??? |
| 流程 3 | ??? |
| 流程 4 | ??? |
如果有人能帮我澄清这一点我会很高兴！
答案1
虽然你上面列出的层次结构看起来有效https://docs.kernel.org/admin-guide/cgroup-v2.html排除了这种层次结构。文档使用了短语“无内部进程约束”。根据这些：
“...非根 cgroup 只有在没有自己的任何进程时才能将域资源分发给其子级。换句话说，只有不包含任何进程的域 cgroup 才能在其“cgroup.subtree_control”文件中启用域控制器。”
由于您的层次结构需要 CGroupB 在 cgroup.subtree_control 中启用 +pids 和 +cpu 并且 Process2 在 CGroupB 中运行，因此它违反了此规则。
在 Debian 11 上运行测试以确认这一点。如果我将 +pids 和 +cpu 放在 CGroupB 中并在 CGroupB 中启动进程 2，则无法在 CGroupC 和 CGroupD 中启动进程 3 和 4。
但是，如果 CGroupB 中没有进程，我可以在 CGroupC 和 CGroupD 中启动进程 3 和 4。CPU
份额的简单（顶部）结果是：
CGroupA：66.3%
CGroupC：22.1%
CGroupD：10.9%
这与应应用的数学运算非常接近，即
CGroupA 进程 1 = 1024/(1024+512)，即 2/3；
CGroupC 进程 3 = 512/(1024+512) * 256/(128+256)，即 2/9；
CGroupC 进程 4 = 512/(1024+512) * 128/(128+256)，即 1/9
PS. 现在够了...我还有更多结果，如果你感兴趣的话可以发邮件/DM...
干杯
弗农
出现细微差异的原因是，cgroupv2 层次结构的其余部分（例如 system.slice）中仍有其他进程继续运行。