在高性能计算环境中，作业通常由大量并行进程组成，进程在物理核心之间的调度行为直接决定了缓存命中率、内存访问延迟和整体吞吐量。CPU pinning（又称CPU绑定或CPU亲和性）指的是将进程或线程显式地固定到特定的CPU核心或一组核心上，防止操作系统调度器将其迁移到其他核心。默认情况下，Linux内核的完全公平调度器（CFS）会根据负载均衡策略将进程在可用核心之间迁移，这种迁移虽然有利于交互式系统的响应性，但对计算密集型HPC应用却往往带来严重的性能抖动。
当进程从核心A迁移到核心B时，其私有L1和L2缓存中的热数据全部失效，需要重新从共享L3缓存或主内存中加载，这被称为缓存冷启动。此外，如果迁移跨越了NUMA节点，后续内存访问可能落入远端节点，延迟可能增加一倍以上。对于迭代求解器、矩阵运算等对内存带宽敏感的应用，这种无规律的迁移可能使性能下降20%甚至更多。因此，在HPC集群中实施CPU pinning是保证可重复性和性能稳定性的基础手段。
从操作系统层面看，CPU亲和性可以通过sched_setaffinity系统调用进行设置。下面是一个简单的C语言示例，将当前进程固定到编号为2的CPU核心：
#define _GNU_SOURCE
#include <sched.h>
#include <stdio.h>
#include <unistd.h>
int main() {
cpu_set_t set;
CPU_ZERO(&set);
CPU_SET(2, &set); /* 绑定到CPU 2 */
if (sched_setaffinity(0, sizeof(set), &set) == -1) {
perror("sched_setaffinity");
return 1;
}
printf("当前进程绑定到CPU 2\n");
while (1) {
/* 模拟计算 */
}
return 0;
}
在实际作业中，手动为每个进程调用该系统调用并不方便，因此更常见的做法是利用资源管理器或MPI库提供的绑定功能，在启动作业时统一配置。接下来我们重点介绍主流HPC调度器的支持情况。
主流HPC调度器中的CPU绑定配置
Slurm是目前最广泛使用的HPC作业调度器之一，它提供了丰富的CPU绑定选项，可以在提交脚本中直接配置。最核心的参数是--cpu-bind，用于指定绑定粒度，可选值包括none、cores、sockets、threads、verbose等。例如--cpu-bind=cores表示将每个任务绑定到一个独立的物理核心，--cpu-bind=sockets则绑定到整个CPU插槽。此外，--hint=nomultithread可以告诉调度器不要使用超线程，从而避免将任务调度到同一物理核心的两个逻辑线程上。
下面是一个典型的Slurm作业脚本片段，展示了如何在两个节点上各运行16个MPI进程，并将每个进程绑定到一个物理核心：
#!/bin/bash #SBATCH --nodes=2 #SBATCH --ntasks-per-node=16 #SBATCH --cpus-per-task=1 #SBATCH --cpu-bind=cores #SBATCH --hint=nomultithread srun --cpu-bind=cores ./my_mpi_app
另一个重要参数是--ntasks-per-core，它控制每个物理核心上允许运行的任务数。如果设置为1，则每个核心只运行一个任务，相当于完全独占核心；若设置为2，则允许使用超线程。在提交脚本中还可以使用--cpus-per-task来为每个任务预留的CPU数量，如果该值大于1，则任务可能以多线程方式运行，此时绑定策略需要结合--cpu-bind进一步细化。Slurm还支持--cpu-bind=map_cpu:等高级映射方式，可以精确指定任务到CPU的映射表，适合对拓扑有特殊要求的应用。
对于PBS/Torque系列调度器，虽然没有Slurm那样细粒度的原生绑定参数，但通常结合numactl或mpirun的绑定选项来实现。例如在PBS作业脚本中，可以使用mpirun --bind-to core（OpenMPI）或mpiexec -bind-to core（MPICH）来强制绑定。部分PBS衍生版本如PBS Pro也提供了-l place=scatter:excl等放置策略，用于将任务分散到不同节点或核心，避免共享。
应用层亲和性设置与OpenMPI/MPICH实践
除了调度器层面，MPI实现本身也提供了强大的进程绑定能力，通常与调度器配置互补使用。OpenMPI的--bind-to选项允许指定绑定级别，常见取值有none、core、socket、numa等。例如mpirun --bind-to core -np 16 ./app会将每个MPI进程绑定到一个单独的核心。如果同时使用OpenMP线程，则需要结合--map-by参数，例如--map-by ppr:4:socket:pe=4表示每个socket上放置4个进程，每个进程预留4个CPU（可用于4个OpenMP线程）。
MPICH及其衍生版本（如Intel MPI）使用类似的-bind-to参数，但在一些较新版本中推荐使用环境变量MPIR_CVAR_CH3_RMA_EAGER_THRESHOLD等，不过绑定主要通过mpiexec -bind-to core实现。在实际集群中，如果同时使用Slurm和OpenMPI，建议在作业脚本中显式给出两者一致的绑定设置，避免冲突。例如Slurm中设置--cpu-bind=cores，同时srun会自动传递绑定信息给MPI进程，此时无需再为mpirun添加额外绑定参数，直接使用srun启动即可。
下面是一个结合Slurm和OpenMPI的典型配置，该配置在每个节点上启动8个MPI进程，每个进程绑定一个物理核心，并预留一个核心用于操作系统和后台服务：
#!/bin/bash #SBATCH --nodes=2 #SBATCH --ntasks-per-node=8 #SBATCH --cpus-per-task=1 #SBATCH --cpu-bind=cores #SBATCH --hint=nomultithread srun --ntasks=16 --cpu-bind=cores ./hybrid_app
对于混合MPI+OpenMP的应用程序，绑定策略需要更加谨慎。通常建议将MPI进程绑定到socket或NUMA节点，然后让OpenMP线程在该进程预留的CPU集合内运行，这样可以利用共享缓存和内存带宽。例如使用--map-by socket:pe=4表示每个MPI进程绑定到一个socket，并预留4个CPU供其内部的4个OpenMP线程使用。如果不正确地绑定到单个核心，OpenMP线程将频繁争抢同一个核心，导致严重的线程切换开销。
常见误区与NUMA感知优化策略
在实施CPU pinning的过程中，有几个典型误区需要避免。第一个误区是忽略超线程的影响。许多管理员为了让作业看到更多“CPU”，将--ntasks-per-core=2，并把任务绑定到逻辑线程，但两个逻辑线程共享同一个物理核心的执行单元，对于计算密集型应用，这样做往往得不偿失。第二个误区是只绑定进程而忽略内存亲和性，导致进程虽然固定在CPU上，但其内存却被分配到了远端NUMA节点，此时内存延迟仍然很高。解决方法是配合numactl --cpunodebind=0 --membind=0之类的命令，将内存分配限制在本地节点。
第三个误区是使用静态绑定策略而没有考虑不同作业的特性。例如，通信密集型的应用可能更希望进程分布在不同的socket上以利用多个内存通道，而计算密集型的应用则更倾向于将进程紧密放置以共享缓存。Slurm的--distribution=block|cyclic|arbitrary参数可以控制任务在节点内的分布模式，对于规则网格计算，cyclic分布通常能获得更好的负载均衡。
要深入优化NUMA感知的调度，可以使用lstopo或hwloc-ls命令导出当前节点的硬件拓扑图，确定哪些CPU属于同一个NUMA节点、哪些核心共享L3缓存。然后根据拓扑结构为每个作业定制绑定方案。例如对于双socket节点，如果每个socket有12个物理核心，我们可以让前12个任务绑定到socket 0的核心，后12个绑定到socket 1的核心，同时每个任务使用--mem-bind=local来确保内存访问是本地节点。Slurm通过--cpu-bind=map_cpu:0,1,2,...,11,24,25,...这样的映射可以精确控制，但手动编写映射表比较繁琐，更常见的做法是使用--hint=multithread或--ntasks-per-socket等高层参数让Slurm自动处理。
总之，CPU pinning是一项基础但关键的HPC优化技术，正确的绑定策略能够显著降低作业的运行时抖动，提升集群整体吞吐率。建议集群管理员在提交脚本模板中统一设置合理的CPU绑定参数，并定期使用性能分析工具（如perf、Intel VTune）验证绑定效果，根据实际负载调整策略。
CPU pinning高性能计算调度CPU亲和性修改时间：2026-10-06 05:29:53