今天看到运维的同事在配置nginx的CPU亲和性时候，运维同事说他在所有的机器上都是按照8核的方式来配置worker进程的CPU亲和性的。
但我觉得就是有点不太对劲，就查了一下nginx的处理worker_cpu_affinity的源代码，发现nginx并不会在发现配置错误的时候拒绝启动worker进程，而是仅仅打印一条错误日志“sched_setaffinity() failed”。
如果设置亲和性失败则按照SMP负载策略进行处理，linux的SMP负载均衡是基于进程数的，每个cpu都有一个可执行进程队列，只有当其中一个cpu的可执行队列里进程数比其他cpu队列进程数多25%时，才会将进程移动到另外空闲cpu上，也就是说cpu0上的进程数应该是比其他cpu上多，但是会在25%以内，呈现的是一种梯形分布。
如果都使用8核的方式，那么配置在4核的机器上，就会有约一半进程是按照SMP方式分配CPU的；配置在16核机器上，就会有约一半的CPU核心空闲。
我是喜欢打破砂锅问到底的，那么就顺道写了一些测试程序来研究一下Linux下的CPU亲和性在不同设置的情况下是什么状况。
测试前提：
系统是8个CPU逻辑核心(cpu0-cpu7)。
可以通过cat /proc/cpuinfo查看. 也可以使用 int num_procs = sysconf(_SC_NPROCESSORS_CONF); 获取CPU逻辑核心的数量
#define _GNU_SOURCE
#include <sched.h>
#include <unistd.h> /* sysconf */
#include <stdlib.h> /* exit */
#include <stdio.h>
//cat /proc/cpuinfo
//gcc cpu_affinity_test.c -o cpu_affinity_test
//ps -eo pid,args,psr | grep cpu_affinity_test
int main(void)
{
cpu_set_t mask;
CPU_ZERO(&mask);
CPU_SET(7, &mask);
pid_t cur_pid = getpid();
/* Set the CPU affinity for a pid */
if (sched_setaffinity(cur_pid, sizeof(cpu_set_t), &mask) == -1) {
perror("sched_setaffinity");
//exit(EXIT_FAILURE);
}
while(1){
printf("hi\n");
usleep(1000);
}
return 0;
}
运行之后，
ps -eo pid,args,psr | grep cpu_affinity_test 查看该进程所占用的cpu，
可以看到这个程序一定是运行在cpu7上。
如果把 CPU_SET(7, &mask);
修改为 CPU_SET(8, &mask);
再编译运行，则CPU亲和性设置会失败，系统会随机给该进程分配一个cpu，但也会固定下来。
如果修改为 CPU_SET(6, &mask); CPU_SET(7, &mask);
再编译运行，理论上会绑定两个CPU，由于这个进程再每次打印之前会休息1秒，所以基本都是在占用cpu6， 如果再修改一下程序，把休息时间修改为1毫秒，则会发现该进程会交替使用cpu6和cpu7。
如果修改为 CPU_SET(6, &mask); CPU_SET(8, &mask);
再编译运行，则cpu6被绑定成功，而cpu8是不存在的，所以该进程就只会在cpu6上运行。
备注： linux的SMP负载均衡是基于进程数的，每个cpu都有一个可执行进程队列，只有当其中一个cpu的可执行队列里进程数比其他cpu队列进程数多25%时，才会将进程移动到另外空闲cpu上，也就是说cpu0上的进程数应该是比其他cpu上多，但是会在25%以内。它也自带负载均衡策略，可以在运行时将某些进程从某一个cpu核心的进程队列移到另外一个cpu核心的进程队列。
https://my.oschina.net/xuhh/blog/755825