taskset不能解决所有CPU绑核问题，因其不继承子进程和线程的亲和性，且内核调度器可能迁移任务；需配合pThread_setaffinity_np()、cgroups v2或isolcpus等机制实现真正隔离。
为什么 taskset 不能解决所有 CPU 绑核问题
直接用 taskset -c 0,1 ./app 看似绑定了 CPU，但子进程、线程默认不继承亲和性，且内核调度器仍可能在负载不均时迁移任务。尤其当应用使用 pthread_create 启动新线程，或调用 fork() 派生子进程时，它们的 cpus_allowed 会被重置为全核掩码。
实操建议：
- 对多线程程序，主线程设置亲和性后，每个新线程创建前需显式调用
pthread_setaffinity_np()，否则线程可能跑在任意核上 - 用
cat /proc/验证实际生效的掩码，注意十六进制掩码与逻辑 CPU 编号的映射关系（例如/status | grep Cpus_allowed_list Cpus_allowed_list: 0-3表示 CPU 0~3，而Cpus_allowed: 0000000f是等价的十六进制） - 避免在容器中仅靠
taskset：docker/kubernetes 的--cpuset-cpus会通过 cgroups v1 的cpuset.cpus或 cgroups v2 的cpuset.cpus文件强制约束，比用户态绑定更底层、更可靠
sched_setaffinity() 和 pthread_setaffinity_np() 的关键区别
前者作用于整个进程（thread group），影响主线程及其后续 fork 出的子进程（但不自动传递给 pthread 创建的线程）；后者只作用于指定线程 ID，必须对每个线程单独设置，且需在 pthread_create() 返回后立即调用——若线程已开始执行，再设亲和性可能被内核忽略或延迟生效。
常见错误现象：pthread_setaffinity_np() 返回 0（成功），但 top -H -p 显示某线程仍在其他 CPU 上运行。原因通常是线程已进入调度队列，内核尚未完成迁移；此时应配合 sched_yield() 或短暂 nanosleep() 让出 CPU，促使其被重新调度到目标核。
参数差异：
-
sched_setaffinity(pid_t pid, size_t cpusetsize, const cpu_set_t *mask)：pid=0表示当前线程，pid>0可设任意进程（需权限） -
pthread_setaffinity_np(pthread_t thread, size_t cpusetsize, const cpu_set_t *mask)：只能设本进程内的线程，且thread必须是活跃的（未 detach 且未退出） - 两者都要求
cpusetsize == sizeof(cpu_set_t)，传错大小会导致静默失败或段错误
实时调度策略（SCHED_FIFO）在多核下的陷阱
启用 SCHED_FIFO 后，只要线程就绪且优先级高于同核其他任务，就会抢占执行——但这仅限于同一 CPU。若线程绑在 CPU 2，而高优先级 SCHED_FIFO 线程在 CPU 3 上持续运行，CPU 2 仍可能被普通线程占满，导致你的实时线程饿死。
性能与兼容性影响：
- 必须用
chrt -f -p 50提升优先级（1~99），且需RLIMIT_RTPRIO权限（普通用户通常需sudo setrlimit -r 99或配置/etc/security/limits.conf） -
SCHED_FIFO线程不会主动让出 CPU，若逻辑有死循环或长阻塞，整颗 CPU 将无法响应其他任务，系统可能假死 - 在超线程（SMT）开启的 CPU 上，同一物理核的两个逻辑核（如 CPU 0 和 CPU 4）共享缓存与执行单元，将两个
SCHED_FIFO线程分别绑在这两个逻辑核上，反而加剧资源争抢，延迟升高
cgroups v2 的 cpuset 如何真正隔离 CPU 资源
cgroups v1 的 cpuset 子系统存在设计缺陷：父组允许的 CPU 集合变更后，子组不会自动同步更新，导致“允许但不可用”状态；而 cgroups v2 将 cpuset.cpus 和 cpuset.mems 统一为单层、原子生效的接口，且支持 cpuset.cpus.effective 实时反映实际可用 CPU 列表。
实操要点：
- 启用 cgroups v2 需内核启动参数含
systemd.unified_cgroup_hierarchy=1，并确认mount | grep cgroup输出包含cgroup2 - 创建隔离组：
mkdir -p /sys/fs/cgroup/myapp
echo '0-1' > /sys/fs/cgroup/myapp/cpuset.cpus
echo '0' > /sys/fs/cgroup/myapp/cpuset.mems
echo $$ > /sys/fs/cgroup/myapp/cgroup.procs—— 此时当前 shell 及其子进程全部受限于 CPU 0~1
- 关键细节：
cpuset.cpus设置的是“可分配 CPU”，但若父组（如/sys/fs/cgroup）本身只允许 CPU 0~3，则子组不能超出该范围；且cpuset.cpus.effective才是进程实际能调度到的 CPU，它会动态剔除因热插拔、内核隔离（isolcpus）等原因失效的核
真实场景里，最易被忽略的是 CPU 隔离（isolcpus 内核参数）与 cgroups 的协同——不加 isolcpus，即使绑核，内核后台线程（ksoftirqd、kworker）仍可能抢占目标 CPU；但加了之后，又必须确保业务进程被显式移到这些隔离核上，否则它们将彻底空转。