perf是唯一能捕获真实线程级调度行为的工具，通过perf record -e sched:sched_switch -p PID采集调度事件，再用perf script | stackcollapse-perf.pl | flamegraph.pl生成调度热图，直观反映线程在CPU间的迁移频次与绑定稳定性，从而精准评估并行效率。
lscpu 能看出线程数，但看不出并行效率
lscpu 只提供静态拓扑：比如 Thread(s) per core: 2 表示超线程开启，CPU(s): 48 是逻辑总数。但它完全不反映实际运行时的并行利用情况——比如 48 个逻辑 CPU 是否真被填满、有没有大量空转、线程是否在不同核心间频繁迁移。这些才是“并行效率”的核心。
用 perf record + perf report 看真实调度热图
Linux 内核自带的 perf 是唯一能捕获真实线程级调度行为的工具，它记录的是内核调度器实际把线程扔到哪个 CPU 上、停留多久、是否被抢占或迁移。
- 先确认目标进程 PID（比如
3883），然后采集 30 秒调度事件：sudo perf record -e sched:sched_switch -p 3883 -- sleep 30 - 生成火焰图式调度热图：
sudo perf script | awk '{print $9,$13}' | sort | uniq -c | sort -nr | head -20
输出类似1245 cpu0/3883，表示该线程在 cpu0 上被调度了 1245 次 - 更直观的方式是导出为 FlameGraph：
sudo perf script | stackcollapse-perf.pl | flamegraph.pl > sched-flame.svg
横轴是 CPU ID，纵轴是调度频次堆叠，越宽越说明该线程长期绑定某核；若左右来回跳，则并行效率低
top -H 和 htop 的“线程视图”只是快照，不是效率图
top -H 或 htop 按线程（TID）排序，能看到每个线程当前的 %CPU，但这只是瞬时采样值。它无法告诉你：这个线程是不是刚从 cpu2 迁移到 cpu5、有没有因锁竞争反复休眠唤醒、是否因 NUMA 远程内存访问拖慢——这些才是并行效率瓶颈的根源。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 误判常见：看到多个线程
%CPU都接近 100%，就以为“并行很好”，其实它们可能全挤在同一个物理核上争抢资源 - 关键线索藏在
/proc/<pid>/status</pid>的voluntary_ctxt_switches和nonvoluntary_ctxt_switches：后者高，说明频繁被内核抢占或等待 I/O，本质是串行阻塞
别信“CPU 使用率图表”代替并行效率图
用 top -b -n 1200 -d 0.5 -p <pid></pid> 导出 %CPU 到 CSV，再画折线图——这只是单个进程的总体负载曲线，和“多线程并行效率”无关。它甚至不能区分：是 8 个线程各跑 12.5%，还是 1 个线程跑 100% 其余 7 个彻底空闲。
- 真正要问的是：线程是否均匀分布在物理核上？是否跨 NUMA 节点访问内存？是否因锁或信号量互相等待？
- 这些问题只能靠
perf sched、perf record -e cycles,instructions,cache-misses或pidstat -t -u 1的%usr/%sys分解来逼近
并行效率不是数字，是调度行为本身。所有“图”都只是对行为的投影，而最易被忽略的，是那些没被调度的线程——它们安静地躺在 runqueue 里，等一个没人争抢的核。
