cgroup v2 下 SCHED_FIFO 线程的 CPU 到底该用 cpu.max 还是 rt_runtime_us 限？同节点两个 RT 容器互相抢占怎么隔离？

【背景】 12 节点集群（K8s 1.28.9，containerd 1.7.13，内核 5.15.0-91，cgroup v2），跑两类实时采集业务，各自一个 Pod、一个 RT 线程：

• 容器 A：电机控制闭环，SCHED_FIFO prio=98，绑核 0-1（cpuset），控制周期 5ms，要求 P99 ≤ 10ms
• 容器 B：振动采集，SCHED_FIFO prio=90，绑核 4-5（cpuset），采集周期 10ms，要求 P99 ≤ 30ms 两个容器 cpuset 完全不重叠，理论上互不抢核。

【现象】

1. 给两个容器都配了 cpu.max=200000 100000（= 2 核上限）。但 A 线程 busy-loop 时（一段 8ms 的纯计算段），观察 cpu.stat 里 nr_throttled / throttled_usec 没有增长，/proc/<pid>/schedstat 显示 A 线程在这 8ms 内拿到了全部 16ms 的核时间（2 核 × 8ms），说明 cpu.max 对这个 RT 线程完全没生效。
2. 更糟的是：当 B 容器线程也进入 busy 段时，A 的 P99 从 6ms 跳到 45ms。抓 rt_throttled 计数发现是节点级 kernel.sched_rt_runtime_us（默认 950000）打满后 A 被 throttle——也就是说两个本不共享核的 RT 容器，被全局 RT 带宽限流"连坐"了。
3. 把 kernel.sched_rt_runtime_us 调到 -1（不限）后 A 的 P99 恢复，但 B 的 busy 段会持续占满核 4-5，导致节点上另一个普通 CFS 的日志 Pod 出现 200ms 级卡顿。

【已尝试】

• 调 cpu.max → 对 RT 线程无效（见上面现象 1）
• 调 kernel.sched_rt_runtime_us=-1 → A 恢复，但 B 反过来压 CFS
• 在容器里给 RT 线程加 usleep(1000) 让出 → 抖动从 45ms 降到 12ms，但引入的 sleep 时间本身又成了新的抖动源
• 看 sched_rt_period_us 默认 1000（即 RT 每 1ms 周期最多用 950μs），改成 10000/9500 后 A 的 8ms busy 段被切成 8 片，每片之间让出，P99 回到 7ms，但 B 的 10ms 采集段被切成 10 片，P99 反而从 15ms 升到 22ms

【期望得到的答案】

1. cgroup v2 下，对一个 SCHED_FIFO 线程，正确的 CPU 带宽控制旋钮到底是哪个？cpu.max（CFS bandwidth）是否对所有非 CFS 任务都不生效？内核里 RT 带宽是 sched_rt_runtime_us / sched_rt_period_us（全局）还是 cgroup 的 cpu.max？
2. 同节点多个 RT 容器（不同 prio、不同 cpuset）共享全局 RT 带宽导致互相 throttle，有没有 cgroup 级的 RT 带宽隔离方案？（比如 cgroup v2 的 cpu.max 是否对 RT 无效、是否有 cgroup 级的 rt_runtime 字段？）
3. 实操上，对"RT 线程不能 throttle、但不能压 CFS"这个矛盾，社区里比较稳的配法是什么？是调 sched_rt_period_us + 在业务侧让出，还是用 isolcpus + nohz_full 把 RT 核从 CFS 调度器里摘出来？
4. 有没有人踩过 SCHED_FIFO + SCHED_RESET_ON_FORK + 容器 entrypoint 三层叠加后，业务线程实际 prio 被 reset 掉的坑？怎么验证容器内 RT 线程的真实 prio 没被 runtime 重置？

【参考】

• 之前有人问过 cpuset 隔离后仍有 200ms 抖动的问题（id=661），但那是单 RT 任务 + 邻居 CFS，我没找到"两个 RT 容器互相连坐"的讨论
• 也看到过 cpu.max 对 CFS 任务的限流陷阱（id=1481），想确认 RT 线程是否完全绕开这套机制

希望有人给过生产环境的实测数据（schedstat / rt_throttled 计数 + 具体参数值），比纯理论推导更有用。