CPU 亲和性与绑核：为什么绑核后性能反而下降？

Linux 调度子系统技术文档系列 · 第 14 篇

作为 Linux 内核调度子系列的第 14 篇，我们来探讨一个在实践中反复出现、却又常常被误解的话题：CPU 亲和性（CPU affinity）。几乎所有做过性能调优的工程师都遇到过这样的场景：为了消除上下文切换开销，把关键进程绑到特定 CPU 上，结果吞吐量不升反降。直觉告诉你绑核是银弹，但内核调度器的行为往往比直觉复杂得多。

绑定 CPU 后性能反而下降：反直觉的场景

一个 Redis 实例跑在 16 核服务器上，运维工程师用 taskset -c 4 将它绑到 CPU 4 上，期望减少缓存失效和上下文切换。前半段一切正常，延迟降低、抖动消失。但当流量翻倍后，CPU 4 跑到了 100%，而旁边 15 个核的平均利用率不到 20%。Redis 的 QPS 被单核算力封顶，性能甚至低于绑核前的状态。

这不是个例。数据库连接池线程绑核、Nginx worker 绑核、Java GC 线程绑核——几乎每一次绑核操作都面临同样的风险：绑核消除了负载均衡的可能性，当工作负载超出单核承载能力时，系统失去了自我调节的弹性。

绑核本质上是一把双刃剑：它用缓存亲和性（cache affinity）换取了负载均衡（load balancing）的能力。理解这把剑的双面性，需要深入内核的 CPU 亲和性数据结构和执行路径。

核心数据结构：cpus_mask、cpus_ptr 与 user_cpus_ptr 是什么

Linux 内核在 task_struct 中用三个紧密相关但职责分明的字段来管理任务的 CPU 亲和性。它们之间的关系可以用一句话概括：cpus_mask 是内核允许运行的 CPU 集合，cpus_ptr 是当前有效的指针，user_cpus_ptr 是用户态设置的掩码备份。

sched.h 展示了这三个字段在内核中的定义位置：

这四个字段构成了 CPU 亲和性的完整体系：

为什么要分离 cpus_ptr 和 user_cpus_ptr

这是理解 CPU 亲和性机制的关键。假设用户把任务绑到了 CPU 0 和 CPU 1，但随后 CPU 0 被热拔除（hot-unplug）。如果内核直接修改 user_cpus_ptr，用户下次查询亲和性时会得到一个被内核篡改过的掩码——用户并不知道自己的设置被改过了。

内核的做法是：保持 user_cpus_ptr 不变（CPU 0, 1），但临时修改 cpus_mask 为仅剩 CPU 1。cpus_ptr 在正常情况下指向 cpus_mask，在迁移禁用（migrate disable）等特殊场景下则可能指向临时掩码。这种分离设计保证了用户态看到的设置是纯粹的，内核态看到的集合是实际的，两者互不干扰。

当 CPU 0 重新上线时，内核会恢复 cpus_mask 为 user_cpus_ptr 的值，任务重新获得两个 CPU 的运行权限。整个过程对用户态完全透明。

PF_NO_SETAFFINITY：保护内核线程的盾牌

PF_NO_SETAFFINITY 是 task_struct.flags 中的一个标志位：

PF_NO_SETAFFINITY 的作用是保护关键内核线程不被用户态随意绑定。内核线程（如迁移线程 migration/N、RCU 回调线程 rcu_sched、写回线程 kworker）需要运行在特定 CPU 或全部 CPU 上才能正常工作。如果用户用 taskset 把 migration/0 绑到 CPU 3，整个 CPU 0 的任务迁移能力就会瘫痪。

内核线程在创建时会被设置这个标志，sched_setaffinity 系统调用在执行时会检测它。这就像一栋大楼的消防通道——普通员工不能随意更改它的位置和方向，只有系统管理员才能调整。内核线程就是系统的消防通道，必须保证它们在需要的时候能在正确的 CPU 上出现。

执行路径追踪：sched_setaffinity 到 migrate_task

从用户态调用 sched_setaffinity 到任务真正迁移到目标 CPU，内核要走一条精心设计的保护路径。这条路径涉及三层锁、多重验证和状态机管理。

core.c 中的入口函数展示了完整的亲和性设置流程，包含掩码交集计算和锁获取：

这段代码的核心逻辑是：新设置的亲和性掩码不能脱离用户之前设定的范围。如果用户之前把任务绑到 CPU 0-3，现在又设置一个 CPU 4-7 的掩码，内核会将两者取交集——结果为空，设置失败。这种设计保证了用户态设置的亲和性约束是累积的，不会被意外覆盖。

进入 __set_cpus_allowed_ptr_locked 后，内核执行验证并选择目标 CPU。core.c 中的关键逻辑包括：

cpumask_any_and_distribute 不是简单地选择第一个可用的 CPU，而是以某种方式分散选择，避免大量任务同时迁移到同一个 CPU 上。这是内核应对群体效应的一个精巧设计。

select_fallback_rq：亲和性机制的安全网

select_fallback_rq 是亲和性机制的最后一道安全网。当一个任务正在运行的 CPU 被热拔除，或者任务的亲和性掩码收缩到不包含当前 CPU 时，调度器调用这个函数为任务寻找新的落脚点。

core.c 中的 select_fallback_rq 展示了一个三阶段回退策略：

回退策略的三阶段设计是内核健壮性的典范：第一阶段尊重 cpuset 约束（通常是 cgroup 或 systemd 设置的资源边界）；第二阶段扩大到所有可能的 CPU（即 cpu_possible_mask）；第三阶段强制执行，确保任务无论如何都能获得一个可运行的 CPU。这种"先礼后兵"的策略保证了系统在任何极端情况下都不会出现任务无处可去的死锁。

__migrate_task：最终迁移

当目标 CPU 确定后，__migrate_task 执行最终迁移。is_cpu_allowed 的二次检查是防御性编程的体现：在任务被选中迁移到实际迁移的短暂窗口中，用户可能又调用了 sched_setaffinity 修改了掩码。内核必须确保任务不会迁移到一个已经不再允许的 CPU 上。

完整的调用链如下：

绑核性能下降的深层原因

回到最初的问题：为什么绑核后性能反而下降？核心矛盾不在绑核本身，而在绑核改变了内核调度器的行为假设。

缓存亲和性与负载均衡的权衡

绑核的初衷是好的：让任务始终在同一个 CPU 上运行，充分利用 L1/L2 缓存中的数据，减少缓存失效带来的性能损失。对于缓存敏感型工作负载（如 Redis 的内存访问、数据库的索引查找），缓存命中率的提升确实可以带来显著的性能改善。

但这种收益是有代价的。内核的负载均衡器在 can_migrate_task() 中检查 cpus_ptr 掩码，发现目标 CPU 不在允许列表后，直接放弃迁移。当绑核任务的负载突然增加时，负载均衡器无能为力——它不能把任务推到空闲的 CPU 上，因为亲和性约束禁止这样做。

性能下降通常发生在以下场景：

1. 单核算力封顶
   ：绑核后任务的吞吐量受限于单核的最大算力，即使其他核完全空闲
2. 中断干扰
   ：绑核的 CPU 可能同时处理大量硬件中断（网卡、磁盘），中断处理与任务竞争 CPU 时间
3. 频率调节受限
   ：CPU 频率调节器（governor）基于整体负载调节频率，绑核任务可能导致频率策略选择不当
4. 超线程干扰
   ：绑核到逻辑 CPU 而非物理 CPU，SMT 兄弟线程可能消耗共享执行单元

Kubernetes CPU Manager 的 static 策略

Kubernetes 的 CPU Manager 组件实现了容器级别的绑核。在 static 策略下，Guaranteed 类型的 Pod（CPU 请求等于限制）会被绑定到独占的 CPU 核上。CPU Manager 本质上是在调用 cpuset cgroup 的 cpuset.cpus 接口，内核底层执行的正是我们追踪的 set_cpus_allowed_ptr 路径。

Kubernetes 的设计者也意识到了绑核的风险：static 策略只对 CPU 请求等于限制的 Pod 生效。如果 Pod 的 CPU 请求小于限制，CPU Manager 不会分配独占核，而是让调度器的负载均衡器继续发挥作用。这是一种有节制的绑核——只在确定性收益最高的场景下才启用。

numactl 与 NUMA 亲和性

numactl 命令控制的是 NUMA 层面的亲和性，与 CPU 绑核正交。numactl --cpunodebind=0 --membind=0 将进程绑定到 NUMA 节点 0 的 CPU 和内存上。在 NUMA 系统上，CPU 绑核和 NUMA 绑核经常配合使用：先用 numactl 确定 NUMA 节点范围，再用 taskset 在节点内选择具体 CPU。

NUMA 亲和性对性能的影响甚至比 CPU 亲和性更大。跨 NUMA 节点访问内存的延迟是本地节点的 2-3 倍，对于内存密集型工作负载，NUMA 错误绑定的损失远超缓存失效的损失。

taskset 命令的工作原理

taskset -c 4,5,6 pid 背后执行的是一个简单的系统调用：

taskset 将用户输入的 CPU 列表转换为 cpumask 位图，通过 sched_setaffinity 系统调用传递给内核。内核验证掩码的有效性（所有 CPU 必须在 cpu_possible_mask 范围内），然后调用我们追踪过的 set_cpus_allowed_ptr 路径。

值得注意的是 taskset -p pid（查询模式）返回的是 user_cpus_ptr 的值，而非 cpus_mask。这意味着即使内核因为 CPU 热拔除临时修改了实际的运行集合，用户看到的仍然是最初设置的掩码。这正是 cpus_ptr 和 user_cpus_ptr 分离设计的直接体现。

总结

CPU 亲和性机制是内核调度器中最容易被误解的子系统之一。它的核心架构可以概括为三个要点：

三层掩码设计——cpus_mask 存储实际允许的 CPU 集合，cpus_ptr 提供当前有效指针，user_cpus_ptr 保持用户设置的原始值。三者分离保证了内核态和用户态的视图互不干扰。

安全网回退机制——select_fallback_rq 的三阶段回退（cpuset → possible → force）确保任务在任何极端情况下都不会无路可走。这是内核健壮性设计的典范。

保护内核线程——PF_NO_SETAFFINITY 标志保护关键内核线程不被用户态随意绑定，维持系统的基础运转能力。

绑核不是银弹，它用负载均衡的灵活性换取缓存亲和性的确定性。理解内核的亲和性机制，才能在绑与不绑之间做出正确的选择。

思考题 1：如果你的服务同时绑核并启用了 CPU 频率动态调节（cpufreq），绑核会导致频率调节器的采样偏差吗？如何验证？

思考题 2：在一个 4 NUMA 节点、每节点 32 核的服务器上，MySQL 的 InnoDB 线程应该绑到哪个范围？为什么不建议绑到单个 CPU 核？

延伸阅读：查看 kernel/sched/core.c 中的 affine_move_task 函数，理解内核如何通过 stopper 线程安全地执行跨 CPU 迁移，而不丢失任务状态。

本系列文章基于 Linux 6.19.13 内核源码
采用 CC BY-NC-SA 4.0 协议，转载请注明出处