pidstat -w 输出 cswch/s 和 nvcswch/s 可定位进程/线程级自愿与非自愿切换，结合 /proc/[pid]/task/[tid]/stat 的 processor 字段可粗略归因到 CPU 核，但内核不提供“每核每线程切换开销”原生指标，需手动聚合分析。
直接看 pidstat -w 输出的 cswch/s 和 nvcswch/s，再结合 /proc/[pid]/task/[tid]/stat 中的 processor 字段做线程级归类，才能逼近“多核并行任务执行过程中的上下文切换开销”——Linux 内核不提供现成的“每核每线程切换开销”指标，必须自己拼。
为什么不能只看 vmstat 的 cs 列
vmstat 的 cs 是系统级总和，完全不区分 CPU 核、进程或切换类型。它告诉你“总共切了 8000 次/秒”，但无法回答“是 8 个线程在 8 个核上各切 1000 次，还是 1 个线程在单核上被反复抢占导致 8000 次非自愿切换”。更关键的是：cs 不拆分自愿/非自愿，而这两者的开销差异极大——nvcswch/s 高往往意味着调度器被迫频繁介入，寄存器+TLB+流水线清空成本真实存在；cswch/s 高更多反映 I/O 或锁等待，CPU 本身可能很空闲。
如何用 pidstat -w 定位到具体线程的切换行为
执行 pidstat -w -t 1（加 -t 才显示线程）：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
-
cswch/s高且%CPU低 → 线程频繁阻塞，查它在等什么：strace -p [tid]看系统调用，或cat /proc/[tid]/stack看内核栈 -
nvcswch/s> 50 且%CPU也高 → 很可能是线程数远超 CPU 核数，或锁竞争激烈导致调度器不断重排；此时perf record -e sched:sched_switch -a sleep 5能看到谁在切谁 - 同一进程下多个线程的
nvcswch/s值差异极大 → 注意是否绑核不均，用taskset -cp [tid]查当前绑定 CPU，再比对/proc/[tid]/stat第 39 字段（processor）是否稳定
怎么把线程切换和 CPU 核关联起来
仅靠 pidstat 无法知道“某个线程在哪颗核上切了多少次”，必须手动聚合：
- 遍历
/proc/[pid]/task/*/stat，提取每条的第 39 字段（processor，索引从 0 开始）和第 14/15 字段（utime/stime） - 同时读
/proc/[pid]/status中的voluntary_ctxt_switches和nonvoluntary_ctxt_switches—— 这是进程级总和，无法按核拆 - 若需线程粒度的切换数，必须读
/proc/[pid]/task/[tid]/status，但注意：该文件不保证原子更新，多次读可能拿到不一致快照 - 真正能按核归因的只有运行时间（
utime/stime），切换次数只能按进程或线程维度统计；所谓“某核上的切换开销”，本质是推断：如果某线程长期固定在 CPU 2 上，且其nvcswch/s突增，那 CPU 2 的调度压力大概率上升
容易忽略的精度陷阱
两次采样间隔太短（utime/stime 差值为 0，算出的占用率失真；而 voluntary_ctxt_switches 等计数器是累计值，差分时若没对齐时间戳（推荐用 clock_gettime(CLOCK_MONOTONIC)），结果会漂移。更隐蔽的问题是：32 位系统上这些计数器可能溢出，必须用 strtoull() 解析，不能用 stoi 或 atoi。
