isolcpus参数隔离的是调度器对指定CPU的可见性，仅允许显式绑定的进程运行，但不阻止内核线程、中断和软中断；需配合nohz_full、rcu_nocbs等参数及正确验证步骤才能实现真正隔离。
isolcpus参数到底隔离了什么
它不禁止进程在指定 CPU 上运行，而是让调度器「假装看不见」这些核心——除了明确绑定（taskset 或 sched_setaffinity）的进程，其他所有普通任务都不会被调度过去。内核线程、中断、软中断默认仍可能落在上面，这点常被误认为「完全隔离失败」。
启动时加参数的正确写法和常见错因
必须写在内核命令行（/proc/cmdline），不是 sysctl 或 runtime 配置。常见错误包括：
- 写成
isolcpus=2,3却忘了加nohz_full=2,3（否则 RCU 会频繁唤醒导致延迟抖动） - 漏掉
rcu_nocbs=2,3，导致 RCU callbacks 在隔离核上执行，破坏实时性 - 用错语法：
isolcpus=1,2,3是对的，isolcpus=cpu1,cpu2或isolcpus=1-3会直接失效 - 没禁用 CPU 热插拔（
nosmt和maxcpus=4等配合项没设，导致隔离核意外上线）
验证是否真正生效的三步检查
光看 /proc/cmdline 不算数，得逐层确认：
- 检查调度器视角：
cat /sys/devices/system/cpu/isolated应输出如2-3；若为空，说明参数未生效或被覆盖 - 看中断分布：
cat /proc/interrupts | head -20，重点关注IO-APIC行，对应列数字应全为 0（否则需用irqbalance --banirq或手动写/proc/irq/*/smp_affinity_list） - 观察负载：
top -p $(pgrep -f "your_realtime_app") -H+1（显示各线程 CPU），再结合ps -o pid,psr,comm -C your_realtime_app，确认 PSR 列稳定落在隔离核上
为什么绑核后还是被抢占？关键遗漏点
即使 taskset -c 2 ./app 成功，以下情况仍会导致非预期调度：
- 应用自己调用了
sched_yield()或阻塞后唤醒，调度器可能换到非隔离核（除非同时设sched_fifo+chrt -f 99） - 子进程继承父进程 CPU mask，但没显式重绑，容易漏掉
-
systemd默认启用 CPUAffinity，若服务文件里写了CPUAffinity=0-1，会覆盖内核层隔离效果 - 容器场景下，
runc或docker的--cpuset-cpus与内核isolcpus冲突，优先级以 cgroup v2 的cpuset.cpus为准
最易忽略的是：隔离核上仍允许 softirq 处理网络包，若用 ethtool -L eth0 combined 1 把网卡队列压到非隔离核，却忘了关 NAPI 轮询或调大 net.core.netdev_budget，软中断爆发时照样打乱实时线程。
