最准方法是查看psr列：ps -o pid,psr,comm -p ，psr值即当前实际运行的cpu编号（从0开始），反映瞬时调度位置，而非亲和性掩码的允许范围。
怎么查进程当前在哪个物理 CPU 核心上运行
直接看 psr 列最准，不是看亲和性掩码——因为掩码只表示“允许跑在哪”，而 psr（processor）显示的是“此刻实际在哪个核上执行”。
用这行命令实时观察：
ps -o pid,psr,comm -p <pid></pid>
输出中 psr 值就是当前调度到的 CPU 编号（从 0 开始）。如果值来回跳变，说明进程还在多个核之间迁移；如果稳定不变，才说明绑定已起作用或负载极低。
-
psr是瞬时快照，建议多执行几次或用watch -n 0.5 'ps -o pid,psr,comm -p <pid>'</pid>持续盯住 - 别只信
taskset -p <pid></pid>输出的十六进制掩码（比如0xff），它可能只是“全开放”，不代表正在跑在哪 - 多线程程序中，
ps -o pid,psr,comm -p <pid></pid>只显示主线程（TID == PID）的psr；要看所有线程，得用ps -T -p <pid></pid>配合psr列
taskset -c 和 taskset -p 的区别与误用点
taskset -c 是“设置 CPU 列表”，taskset -p 是“操作已有进程”——这两个选项必须组合使用才有意义，单独用 taskset -c 不带命令会报错。
常见错误写法：
-
taskset -c 1,3 -p 1234❌：把-p当成-c的子参数，实际是两个独立选项，顺序错导致1234被当成命令名 -
taskset -c 0,2 ./app --arg✅：正确，-c后紧跟 CPU 列表，再跟完整命令 -
taskset -pc 0,2 1234✅：等价于taskset -p -c 0,2 1234，修改已运行进程
注意：taskset -p 0x5 1234 和 taskset -pc 0,2 1234 效果一致（0x5 = 0101₂ → CPU 0 和 CPU 2），但列表写法更直观、不易数错位。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
多线程程序为什么绑了主线程却没效果
默认情况下，taskset 只作用于主线程（TID == PID），子线程创建后继承的是系统默认亲和性（通常是全核开放），不会自动套用主线程的绑定。
- 启动时加
-a：如taskset -ac 1,3 python workload.py，让所有线程一并受限 - 运行中改需显式指定所有 TID：先
ps -T -p <pid></pid>列出线程，再对每个TID执行taskset -p -c 1,3 <tid></tid> - 若线程由第三方库（如 OpenMP、NumPy）内部创建，
-a也不一定全覆盖，此时得在代码里用pthread_setaffinity_np()控制
不加 -a 的典型现象：top 里看到主线程固定在 CPU 1，但其他线程仍在满核乱跳，整体缓存局部性没改善。
绑定后进程还在不同核心间跳，是不是失败了
不一定失败。只要亲和性掩码含多个 CPU（如 -c 2,3），内核就会在其中做负载均衡——这是正常行为，不是 bug。
想真正“钉死单核”，必须确保掩码只含一位：
-
taskset -c 2 ./app✅：只允许 CPU 2 -
taskset 0x4 ./app✅：0x4 = 100₂，也是只对应 CPU 2 -
taskset -c 2,3 ./app❌：这不是“钉死”，是“限池”，内核有权在 2 和 3 之间切换
真正要隔离服务，不能只靠 taskset 临时设置：得配合 systemd 的 CPUAffinity= 持久化配置，或用 cpuset cgroup 独占物理核——否则重启、重调度、内存 NUMA 位置都不可控。
