嵌套cgroups资源分配：父cgroup含进程且有子cgroup时如何分配CPU？

你的理解是否正确？ #

你的结论是正确的，具体分配逻辑拆解如下：

1. 父cgroup“A”拥有50%的CPU硬限制，这是它能调用的最大CPU资源池。
2. 父cgroup“A”的直接资源竞争实体是PID1、PID2和子cgroup“A1”：
   • 默认单个进程在cgroup中的CPU shares值为1024，你设置子cgroup“A1”的shares也为1024，三者的shares比例为1:1:1。
   • 因此父cgroup的50% CPU会被三者平分，每个实体获得约16.666%的绝对CPU资源。
3. 子cgroup“A1”内部的PID3和PID4：
   • 二者的shares比例同样为1:1，会平分“A1”获得的16.666%资源，最终每个进程获得约8.333%的绝对CPU资源。
   • 你设置“A1”的quota/period=1.0，意味着它请求100%的单CPU资源，但由于父cgroup“A”的硬限制更严格，它实际最多只能获得父池的1/3，这个quota设置不会改变最终分配结果。

如何直观理解多层级资源分配逻辑？ #

• 动手实操验证：
  • 用cgroup-tools包创建嵌套cgroup，比如创建父cgroup“A”并设置CPU quota为50%（cgset -r cpu.cfs_quota_us=50000 /sys/fs/cgroup/cpu/A），再创建子cgroup“A1”并设置cpu.shares=1024。
  • 用stress工具在每个实体中启动CPU密集型进程（比如stress -c 1），然后用top、htop或cgget -r cpu.stat /sys/fs/cgroup/cpu/A查看实际CPU占用数据。
• 逐层拆解逻辑：
  • 资源分配是层级递进的：先计算父cgroup给直接子实体（进程/子cgroup）的资源份额，再处理子cgroup内部的分配，每层只关注当前层级的竞争实体，不跨层计算。
  • 区分两种控制机制：
    • shares是相对优先级：只有当资源紧张时才按比例分配，空闲时进程可以使用超出份额的资源；
    • quota/period是硬限制：无论系统资源是否空闲，实体最多只能使用设定的CPU比例。
• 简化模型推导：
  • 把每个cgroup看作一个资源容器，父容器先把自己的资源池分给直接子容器/进程，子容器再把分到的资源池分给自己的内部进程，每层分配都遵循各自的比例规则。

内容的提问来源于stack exchange，提问作者Emanuel Kozerski