Linux taskset / cpuset 的进程 CPU 绑定与 cgroup cpuset 冲突解决

taskset 和 cgroup cpuset 同时生效时，进程最终只能运行在两者 cpu 集合的交集上；/proc//status 中的 cpus_allowed_list 即为该交集结果，是调度器实际遵循的唯一依据。

taskset 和 cgroup cpuset 同时生效时，谁起作用？

当 taskset 和 cgroup v1/v2 的 cpuset 同时配置，进程最终能跑在哪些 CPU 上，取决于两者的交集——不是“覆盖”，也不是“优先级高低”，而是硬性取交集。内核调度器会在两者共同允许的 CPU 集合里选核，超出任一限制都会被拒绝。

常见错误现象：taskset -c 0-3 ./app 启动后，top -H 显示线程仍在 CPU 4 上运行；或者 cat /proc/<pid>/status | grep Cpus_allowed</pid> 返回的掩码比预期窄得多——这往往是因为父进程所属的 cgroup cpuset.cpus 已经锁死了可用范围（比如只允许 CPU 2,3），此时 taskset 再怎么指定 0-3 也无效。

• 使用场景：容器环境（docker/K8s）中手动调试进程时，容易忽略宿主机或 Pod 级别的 cpuset 限制
• taskset 是 per-process 的运行时设置，不持久；cgroup cpuset 是 per-cgroup 的资源边界，对所有子进程继承生效
• 验证顺序建议：先查 cat /proc/<pid>/cgroup</pid> 确认所属 cgroup 路径，再读该 cgroup 下的 cpuset.cpus 和 cpuset.effective_cpus

如何判断当前进程是否被 cgroup cpuset 实际限制？

别只看 taskset -p <pid></pid>，它只反映进程自身的 CPU 掩码，不体现 cgroup 层面的裁剪。真正决定调度权的是 /proc/<pid>/status</pid> 中的 Cpus_allowed_list 字段——这个值已经是 taskset 和 cgroup 取交集后的结果。

常见错误现象：执行 taskset -p <pid></pid> 显示 “0-7”，但 cat /proc/<pid>/status | grep Cpus_allowed_list</pid> 返回 “2-3”，说明 cgroup 已生效且更严格。

• Cpus_allowed_list 是最终生效值，必须以它为准
• cgroup v1 路径通常为 /sys/fs/cgroup/cpuset/<path>/</path>；cgroup v2 统一挂载在 /sys/fs/cgroup/ 下，需通过 cat /proc/<pid>/cgroup</pid> 找到对应子目录
• 如果 cpuset.effective_cpus 为空（或为 0），进程会被冻结——这是容易被忽略的静默故障点

想绕过 cgroup cpuset 限制，只有这三种可行路径

没有“禁用”接口，只有规避方式。强行改 cpuset.cpus 可能导致容器崩溃或 K8s 驱逐，慎用。

• 把进程移到根 cgroup：echo <pid> > /sys/fs/cgroup/cpuset/cpuset.procs</pid>（v1）或 echo <pid> > /sys/fs/cgroup/cgroup.procs</pid>（v2），前提是进程有权限写入目标 cgroup
• 启动前清空父 cgroup 限制：若你控制启动环境（如 systemd service），可在 [Service] 段加 CPUSchedulingPolicy=other 并显式设置 CPUSchedulingPriority=0，同时确保未启用 AllowedCPUs= 类配置
• 用 unshare --user --pid --fork --mount-proc /bin/bash 创建新 user+pid Namespace，再在其中运行 taskset——cgroup 权限随 namespace 重置，但仅适用于调试，不可用于生产服务

cpuset 和 taskset 混用时的性能陷阱

看似“更细粒度控制”，实则容易引发 NUMA 不匹配、缓存抖动和调度延迟升高。尤其当 taskset 把线程绑在某个 CPU，而该 CPU 所属 NUMA node 的内存带宽已被 cgroup 其他进程占满时，延迟可能翻倍。

常见错误现象：绑定后吞吐没升反降，perf stat -e cycles,instructions,cache-misses 显示 cache-misses 暴涨；numastat -p <pid></pid> 显示跨 NUMA 内存访问占比异常高。

• cgroup cpuset 默认不感知 NUMA topology，cpuset.mems 必须显式设置才能绑定内存节点
• taskset 不处理内存亲和，纯 CPU 绑定 + 缺失 cpuset.mems = 高概率跨 NUMA 访存
• 多线程程序慎用 per-Thread taskset：glibc 的 malloc、信号处理等后台线程仍受 cgroup 限制，可能卡在非预期 CPU 上

实际调优时，要么全用 cgroup cpuset 做统一资源划分，要么彻底脱离 cgroup 环境再用 taskset——混合模式下最麻烦的从来不是配置写法，而是排查时得同时盯住三个地方：/proc/pid/status、对应 cgroup 的 cpuset.cpus 和 cpuset.effective_cpus、以及 NUMA 拓扑对齐情况。