LIKWID三合一：CPU拓扑、绑核与性能计数器的HPC性能排查实践

1. 为什么我会把 LIKWID 当成性能排查的默认起点

前两年在一台双路 Skylake 节点上排一个性能问题，同一个 CFD 程序在相同输入下，前后两次运行时间差了 40%。排查方向一开始完全跑偏，怀疑是编译器更新改坏了代码，后来用 LIKWID 的拓扑信息一看，问题根本不在计算逻辑——上一轮脚本里的 numactl 参数被环境变量覆盖，MPI 进程全被塞到同一个 NUMA 节点上，跨 NUMA 访问内存拖垮了整体吞吐。那次之后我养成了一个习惯：任何跑在服务器上的性能测试，第一件事先用 LIKWID 看清楚 CPU 拓扑，再谈后面的事。

LIKWID 这个名字对不跑 HPC 性能工程的人可能有点陌生，它全称是 “Like I Knew What I'm Doing”，来自埃尔朗根-纽伦堡大学 HPC 团队，是一套非常轻量的命令行性能工具集。它把三件高频需求做在了同一个生态里：likwid-topology 看拓扑，likwid-pin 做绑核，likwid-perfctr 读硬件性能计数器。单看每一项，Linux 上都有替代品，比如 lstopo、numactl、perf stat。但当你需要同时控制“机器长什么样、程序跑在哪个核、计数器读的是哪个 CPU 域”的时候，分开用几套工具，光是把 CPU 编号体系对齐就够折腾半天。LIKWID 的价值就在于把这三件事用同一套 CPU 描述语法串起来，这也是标题里“三合一”的真正含义。

先说清楚一个前提：这里说的拓扑，不是电路设计里说的 buck/boost 电源拓扑，也不是 ArcGIS 里的拓扑检查，而是 CPU 的物理层级关系——从 socket、NUMA 节点、缓存，到物理核和逻辑线程。这个拓扑结构直接影响内存访问延迟、缓存命中率、多线程扩展性。很多性能问题，本质上不是代码编译得不高效，而是线程被调度到了错误的位置：本该共享 LLC 的线程被拆到两个 socket 上，或者内存分配落在了远端 NUMA 节点。没有拓扑信息，你连问题出在哪一层都不知道。

和商业工具对比，LIKWID 的定位非常明确。Intel VTune 功能强，但安装重、图形界面在集群上不好使，命令行模式的学习曲线也不低。perf 是 Linux 内核自带的瑞士军刀，读事件很全，但绑核和拓扑梳理不是它的强项，事件命名在不同架构上又经常换。PAPI 更适合做库集成，给应用自己采集数据用，不是一个开箱即用的命令行工具。LIKWID 更像是为 HPC 用户定制的一套轻量方案：单个工具装完，likwid-topology、likwid-pin、likwid-perfctr 全都能用，不需要常驻服务，不需要图形界面，普通用户在共享节点上也能跑起来大部分功能。

这篇东西不会讲太多 LIKWID 的历史，重点放在我怎么在真实节点上用它解决“程序跑得慢但不知道慢在哪”的问题。内容包括三个核心工具的具体用法、我在使用中踩过的坑，以及一套可以直接抄走的评测流程。如果你平时要跑 benchmark、调 OpenMP/MPI 程序、写性能分析报告，或者只是想知道自己花几万块买的机器到底发挥了多大算力，LIKWID 值得花一个下午熟悉一下。

2. 拓扑：先摸清机器再动手

2.1 likwid-topology 输出里到底藏了什么信息

安装好 LIKWID 后，第一个推荐的命令就是 likwid-topology。它会直接打印当前节点的完整硬件层级，看起来大致是这样：

text复制CPU name: Intel(R) Xeon(R) Platinum 8260 CPU @ 2.40GHz
CPU type: Intel Skylake (server) core
CPU clock: 2.40 GHz
...
Socket 0:
  Threads: 0-47
  Cores:   0-23
  ...
NUMA domains:
  NUMA domain 0: CPUs 0-23,48-71
  NUMA domain 1: CPUs 24-47,72-95
Cache:
  L1d cache:  32 KB
  L1i cache:  32 KB
  L2 cache:   1024 KB
  L3 cache:   35.75 MB

这段输出写的是“这台机器上有多少个 socket、每个 socket 下有哪些核、这些核是怎么被超线程复制成逻辑 CPU 的、缓存和 NUMA 域怎么划分”。很多人只看 CPU 型号和核数，直接把 96 个逻辑 CPU 当成 96 个物理核来用，这是最常见的误区。上面这个例子中 48 个物理核，打开超线程后有 96 个逻辑 CPU，两两共享一个物理核。你如果开 96 个线程各绑一个逻辑 CPU，实际是在让线程两两抢同一个执行单元，扩展性不会随线程数线性上升。

另一个值得关注的是 NUMA 域。现代多路服务器上，内存访问延迟并不是均匀的，CPU 访问本地内存比访问远端内存快很多。NUMA 域通常对应一个 socket 直接管理的那部分内存，跨域访问的延迟和带宽损失在某些负载下非常明显。likwid-topology 会把 NUMA 域和 CPU 的映射关系直接列出来，你就可以根据这个决定让一个 MPI rank 或 OpenMP 线程组尽量待在同一域内。

实际使用中，我常加 -c 参数，它会把 CPU 列表压缩成更适合脚本解析的格式，比如 0-23,48-71。这个格式可以直接喂给后面要讲的 likwid-pin 和 likwid-perfctr，不用再手工写一大串 CPU id。如果你第一次上新节点，我建议先跑一句 likwid-topology -c 把结果保存到终端里，后面所有绑核和计数指令都从这里复制 CPU 列表，比每次现猜靠谱得多。

2.2 从拓扑图到绑核语法：LIKWID 的 CPU 域概念

likwid-topology -g 会输出一张文本形式的拓扑示意图，把 socket、NUMA 节点和缓存结构用缩进和括号表现出来。这张图我没有办法在博客里贴完整样例，因为每台机器差异很大，但它的价值在于让你快速确认：哪些 CPU 共享同一个 L3，哪些 CPU 属于同一个 NUMA 域。如果图上看到两个逻辑线程编号差 48 的 CPU 其实在同一个物理核上，你就明白 -c 0-95 这种写法在绑核时有多容易出错了。

LIKWID 的关键设计之一是 CPU 域语法。它不只接受 0-3 这种逻辑 CPU 编号，还支持按 socket、NUMA 域等语义来描述目标，格式类似 S0:0-3、N0:0-3。这里的 S 指 socket，N 指 NUMA 域，后面跟的是该域内的逻辑 CPU 范围。比如 -C S0:0-11 表示“绑到 socket 0 里的逻辑 CPU 0 到 11”，-C N1:0-7 表示“绑到 NUMA 域 1 里的前 8 个 CPU”。这种写法在跨平台复现实验时特别有用，因为不同机器上全局 CPU id 的排布完全不一样，但 NUMA 域 0 的语义是稳定的。

不同发行版和 LIKWID 版本支持的域字母可能略有差异，最稳妥的做法是装完先跑 likwid-pin -h 和 likwid-topology -h 看说明。拓扑、绑核、计数器三个工具共享同一套 CPU 描述语法，这意味着你在 likwid-topology 里看到的一串 N0:0-11，可以直接复制到 likwid-perfctr -C 参数里用，不需要做任何换算。这种一致性才是 LIKWID 省时间的地方。

3. 绑核：让线程待在该待的地方

3.1 likwid-pin 的基本用法

绑核这件事，操作系统默认的调度器在大多数时候是聪明的，但它不知道你的程序是什么内存访问模式、哪些线程需要共享缓存。所以当性能测试要求可复现时，我一定会手动绑核。likwid-pin 的用法非常简单，核心命令就一行：

bash复制likwid-pin -c 0-3 ./myapp

这会把 myapp 的 4 个线程依次绑定到逻辑 CPU 0、1、2、3 上。对于 OpenMP 程序，LIKWID 会通过 libgomp 或 libiomp 的接口识别线程编号，然后逐个 pin 到对应 CPU。程序启动时，likwid-pin 会打印一张线程到 CPU 的映射表，你可以直观看到 PID、线程编号、绑在哪个 CPU 上。-s 参数可以关掉这些诊断输出，脚本环境里会更干净。

更实用的场景是用 -C 加域语法，避免自己数全局 CPU id：

bash复制likwid-pin -C N0:0-15 ./myapp_omp

上面这句话的意思是把 16 个 OpenMP 线程全部绑到 NUMA 域 0 的前 16 个逻辑 CPU 上。如果你的应用需要跨 NUMA 域扩展，可以把域 0 和域 1 都列给它，比如 -C N0:0-7,N1:0-7。这样内存分配、进程迁移、线程调度的整体行为更可控，比单纯写一堆全局 CPU 编号更不容易出错。

对于 MPI 程序，我一般直接配合 likwid-mpirun 使用，它会根据当前节点拓扑自动把不同 rank 分布到不同的 socket 和 NUMA 域上。比如在双 socket 节点上跑 16 个 rank，它会优先每个 socket 放 8 个，尽量让相邻 rank 共享 L3，而不是顺手全塞到 CPU 0-15 上。如果暂时不想引入 likwid-mpirun，也可以先用 mpirun 启动一个包装脚本，脚本里用 likwid-pin 对每个 rank 做精确绑定。但说实话，试过 likwid-mpirun 之后，我不太想再手工写这套逻辑了。

3.2 绑核的几个关键决策点：SMT、NUMA、内存分配策略

绑核最忌讳的是“绑了但绑错位置”。第一个容易踩的是 SMT 超线程。逻辑 CPU 0 和逻辑 CPU 48 可能是同一个物理核的两个线程，你如果绑 0 和 48 两路线程做并行，它们实际在抢一个核的双发射资源。使用 -C 域语法可以缓解这个问题，但更好的方式是先看 likwid-topology 的 thread 排列规则，确认哪两个逻辑 CPU 是兄弟。我习惯在确定线程数之后，给每个物理核只分配一个线程，除非实验本身就在测超线程收益。

第二个是内存分配策略。绑核只解决 CPU 在哪执行的问题，不解决内存页在哪个 NUMA 节点的问题。LIKWID 系列里有个小工具 likwid-memsweeper，会在所有 NUMA 域上预分配并清理内存，不过日常测试中我更常用的是在绑核基础上叠加 numactl --membind，确保内存分配域和 CPU 域一致。比如 likwid-pin -C N0:0-15 numactl --membind=0 ./myapp，这样才能真正把“线程待在域 0、内存也分配在域 0”这件事同时固定下来。

第三个决策点是和 OpenMP 自带绑定策略的关系。GNU 的 OMP_PROC_BIND、Intel 的 KMP_AFFINITY 以及 LIKWID 的 pinning 功能目的相同。如果多个机制同时生效，线程可能被两次迁移，甚至出现相互覆盖，最终实际绑定结果完全不符合预期。我的建议是只保留一个绑定入口。用 LIKWID 时就取消 OMP_PROC_BIND 和 OMP_PLACES 的设置，保持环境干净。真调起来少一层变量，问题定位容易得多。

4. 性能计数器：数据不会骗人

4.1 硬件计数器是怎么被 LIKWID 读出来的

现代 CPU 内部有一组性能监视单元（PMU），专门统计指令数、周期数、缓存未命中、分支预测失败这类微架构事件。这些事件不是默认打开的，需要通过系统接口去配置和读取。Linux 上最常见的是 perf_event_open 系统调用，也就是 perf stat 的底层来源；另外一部分与功耗、频率相关的事件放在 Model Specific Register（MSR）里，需要 msr 内核模块支持。

LIKWID 的 likwid-perfctr 在 Linux 上主要也是走 perf_event 子系统，特殊情况下会访问 MSR 拿 RAPL 功耗计数。它的优势在于，把底层复杂的事件编码封装成一组组“语义化”的性能组，比如 FLOPS_DP、MEM_DP、ENERGY。你不必去查某个 CPU 的原始事件编号，也不需要知道 PMU 寄存器怎么配置，直接给命令指定一个组名，它就会自动把相关事件全部打开并汇总。

硬件计数器有一个限制：同一时刻 PMU 能同时计数的事件数量是有限的，所以 likwid-perfctr 把常用事件组合编译成性能组。这意味着你选了一组，可能就不能同时选另一组里的某些事件。这也是为什么性能分析刚起步时，我会先用几个大组（浮点、内存、功耗）找到瓶颈方向，再针对具体区域用 marker API 做细分采样。

4.2 likwid-perfctr 的常用姿势

最基础的计数器命令和绑核耦合在一起：

bash复制likwid-perfctr -C 0-3 -g FLOPS_DP -O ./myapp

这条命令会在逻辑 CPU 0-3 上运行 ./myapp，并测量双精度浮点操作数。-g FLOPS_DP 是性能组名，-O 表示 CSV 格式输出，适合脚本解析；如果想去掉 -O，默认的人类可读输出信息更丰富，会包含每个线程的计数器明细、总次数、每秒次数等。

我常用的几个性能组在下面这张表里：

比如你想做一个流式内存带宽评估，直接 likwid-perfctr -C 0-15 -g MEM_DP ./bandwidth_test。它会给出读写带宽的实测值，你可以拿它和 STREAM 峰值做对比，判断程序是不是真的把内存带宽吃到瓶颈了。如果跑 FC 类算例发现内存带宽已经接近峰值，那再优化浮点指令数意义不大，瓶颈在数据搬运而不是运算本身，优化方向应该转向数据复用。

-m 参数也值得记一下。默认情况下计数器会按所有被测线程做聚合输出，-m 会把每个线程的计数单独打出来。这个在定位“某些线程特别慢”的时候很有用，比如 16 个线程里有一个计数明显异常，多半是绑核绑到了和其他线程抢资源的 CPU 上，或者系统的中断负载干扰了这个核。

4.3 Marker API：把计数范围缩小到代码区段

likwid-perfctr 默认统计整个程序的运行区间，但真实项目里很多时候我们只关心某个耗时函数或某个迭代循环。这时候就要用 marker API 在代码里插桩。LIKWID 提供头文件和库，支持 C/C++ 和 Fortran，用法跟 OpenMP 的 #pragma 类似，只是更暴露一点：

c复制#include <likwid-marker.h>

int main() {
    LIKWID_MARKER_INIT;
    for (int iter = 0; iter < 100; iter++) {
        LIKWID_MARKER_START("compute");
        // 需要计数的核心计算段
        LIKWID_MARKER_STOP("compute");
    }
    LIKWID_MARKER_CLOSE;
    return 0;
}

编译时链接 LIKWID 库：

bash复制gcc -I${LIKWID_INCLUDE} -o myapp myapp.c -L${LIKWID_LIB} -llikwid

运行方式基本不变，只是需要加 -m 参数让 marker 区段信息显示出来：

bash复制likwid-perfctr -C 0-3 -g FLOPS_DP -m ./myapp

输出里会多出一张按标记名分组的统计表，告诉你 compute 区段内部总共发生了多少次浮点操作、多少个周期、缓存表现如何。这个功能在优化大型代码时非常关键：你不用把整个程序跑完再看总体指标，而是可以把最耗时的三个函数分别插上 marker，直接对比函数之间的微架构差异。我实际用下来，marker 的开销可以忽略不计，却能把性能问题的定位粒度从“程序级”缩小到“函数级”，省掉了大量二分注释代码的时间。

5. 踩坑清单：我第一次用 LIKWID 翻过的五类车

5.1 权限与 perf_event_paranoid

likwid-perfctr 读取硬件计数器离不开 perf_event 子系统。如果内核参数 kernel.perf_event_paranoid 设置太高，普通用户会被拒绝访问 CPU 事件，报错信息通常是 “Permission denied” 或者 “Cannot access performance counters”。检查方法：

bash复制cat /proc/sys/kernel/perf_event_paranoid

这个值一般从 -1 到 3 不等。很多发行版默认是 2 甚至 3，只能读到用户态自身进程的事件，对内核态采样和某些硬件事件不开放。最简单的解法是找管理员把它临时改成 1 或 -1：

bash复制sudo sysctl kernel.perf_event_paranoid=-1

如果连 sysctl 权限都没有，也可以试一下加载 MSR 模块走另一条读取路径：

bash复制sudo modprobe msr

LIKWID 在检测到 perf_event 不可用时，有部分事件可以退回到 MSR 方式读取，但能读的事件会少很多。我的经验是，在一台正经跑性能测试的节点上，直接把 paranoid 设为 -1 是常态。安全策略严格的环境里，至少也应该申请一个“允许读取硬件计数器”的白名单账号。

5.2 事件命名和可用组随架构变化

LIKWID 的性能组名在不同 CPU 微架构上并不完全等价。FLOPS_DP 在 Intel Skylake 上会包含 AVX512 指令的计数，在 AMD Zen 上对浮点指令的拆分可能不同；某些在旧平台上很顺手的组在新平台上直接被标记为不可用。跨架构对比性能数据时，不要拿原始计数器值直接画曲线，而要先看 likwid-perfctr -a 列出的当前架构可用事件列表，确认两个平台上的事件定义是否真的对齐。

我刚用 LIKWID 时犯过一个错误：分别在 Intel 和 AMD 节点上用同一套 FLOPS_DP 组采集数据，然后对比两个平台的浮点性能，后来发现事件编码对“一次 FMA 算几次浮点操作”的统计口径不同，数据完全不可比。正确的做法是：要么用 likwid-perfctr -a 找到两边语义一致的组，要么干脆用 wall time 和实测带宽这种体系结构无关的指标去比。官方文档和 likwid-perfctr -H 会给出每个组的详细说明，换机器前翻一眼不亏。

5.3 虚拟化和容器环境里的坑

LIKWID 在物理机上表现很好，一旦跑在云主机或容器里，情况就复杂了。虚拟机能不能读到硬件计数器，取决于虚拟化层有没有把 PMU 透传给 guest。很多轻量云主机默认不透传，likwid-perfctr 会直接报错，或者返回的全是 0。容器方面，如果没有给容器加适当的 capability，perf_event 同样可能被 seccomp 或 cgroup 拦住。

遇到这种情况，我的处理思路是：先在宿主机或另一个物理节点上跑一遍 likwid-perfctr -a，如果连“列出事件”都失败，说明当前环境根本不具备硬件计数条件，不用浪费时间在环境里折腾，改用 wall-clock 计时和 /proc 下的统计信息做粗粒度分析。在容器里做性能测试还要格外小心 CPU 绑定的假象，容器内看到的 CPU 编号往往经过映射，和宿主机的物理 CPU 编号对不上，绑核参数需要结合实际的 cpuset 来看。

5.4 和 MPI/OpenMP 自带绑定策略打架

这是一个特别隐蔽的问题。likwid-pin 虽然会在程序启动时把线程 pin 到指定 CPU，但 OpenMP 运行库如果在之后也执行自己的 affinity 设置，可能会覆盖 LIKWID 的绑定。比如你设置了 OMP_PROC_BIND=true 和 OMP_PLACES=cores，LIKWID 已经绑好一轮，运行库启动线程时又来一遍，结果就是你看到的实际绑核位置和预期不一致。

排查方法是程序退出后，在 likwid-pin 输出的映射表里核对每个线程的 PID 和 CPU 编号。如果发现线程全部集中在某个奇怪的范围，先检查环境变量里有没有 OMP_PROC_BIND、OMP_PLACES、KMP_AFFINITY、I_MPI_PIN 之类的设置。我的习惯是在基准测试脚本开头统一清空这些变量，只保留 LIKWID 的绑核入口，减少变量的相互干扰。MPI 场景下则更推荐直接用 likwid-mpirun，它内部已经处理了和 MPI 运行时的协调，比手工叠加绑定策略稳定得多。

5.5 计数器读到了，但怎么知道读数对不对

读出一堆数字不等于数据可信。我一般会用两种方式验证。第一种是使用 LIKWID 自带的微基准工具 likwid-bench，比如测内存带宽的 load 基准，理论上它的带宽应该接近硬件上限；如果 LIKWID 读出来的结果明显低于 STREAM 实测或者该型号 CPU 的已知带宽，说明事件配置或权限有问题。第二种是在代码里放一个已知浮点运算量的循环，比如重复执行 N 次矩阵乘法，手动估算 FLOPs，然后看 FLOPS_DP 的输出是否在一个合理的误差范围内。

我印象很深的一次，是在一台旧服务器上所有计数器都返回 0，排了一晚上没结果，最后发现是主板 BIOS 里把 PMU 的虚拟化特性关掉了，Linux 根本读不到事件。这种“读数全是 0”的情况，大概率不是软件问题，而是硬件层面没有暴露计数能力。遇到先别慌，换一台机器跑同一个命令，立刻就能判断是不是环境问题。

6. 一条可以直接拿到集群上跑的工作流

6.1 从拓扑到绑核到计数的最小闭环

我在新节点上调试性能时，会按三步走，每一步都可以对应到一个 LIKWID 命令。

第一步，摸清机器。运行 likwid-topology -c，把 socket、NUMA 域、逻辑 CPU 的映射关系记下来。这一步解决“这台机器有哪些资源”的问题。第二步，固定位置。根据应用是内存密集还是计算密集，决定是绑在单个 NUMA 域内，还是跨域绑内存带宽更高的组合。比如一个 32 线程的 OpenMP 程序，如果它的工作集能塞进单个 NUMA 域的 LLC，我倾向绑成 -C N0:0-31；如果必须访问大内存，则考虑 -C N0:0-15,N1:0-15，并配合 numactl --interleave=all 均衡内存分配。第三步，量化效果。用 likwid-perfctr -C ... -g MEM_DP -O ./app 和 -g FLOPS_DP 各跑一次，把结果存成 CSV。

下面是一个简化但完整的最小脚本：

bash复制#!/bin/bash
APP=./myapp
THREADS=16

# 查看拓扑
likwid-topology -c

# 绑核运行，输出绑核映射
likwid-pin -C N0:0-$((THREADS-1)) $APP

# 计数器采集：浮点性能和内存带宽
likwid-perfctr -C N0:0-$((THREADS-1)) -g FLOPS_DP -O $APP
likwid-perfctr -C N0:0-$((THREADS-1)) -g MEM_DP -O $APP

这条流程跑完，你至少会得到三个关键信息：程序实际运行时间、浮点吞吐、内存带宽。拿到这些数字后，就可以判断性能瓶颈的类型：如果浮点吞吐接近硬件理论峰值，那代码核心循环已经写得很高效，瓶颈可能出现在并行扩展上；如果内存带宽接近峰值，说明数据的搬运速度限制了计算，该考虑内存分配策略、缓存分块或者改变数据结构布局；如果两个指标都不高，多半是延迟瓶颈、同步开销或者资源争抢，这时候就要把 marker API 加进代码，往更细的区间去定位。

6.2 更进一步：结合 marker 和 likwid-bench 做热点分析

当最小闭环暴露出性能问题之后，我会进入第二轮分析。这一轮的核心工具是 marker API 和 likwid-bench。marker API 前面已经写过用法，适合定位“哪些函数最耗时、这些函数的微架构表现如何”。而 likwid-bench 适合做硬件能力上限探测，比如你可以先跑：

bash复制likwid-bench -t load -W S0:0-3

指定在 socket 0 的前 4 个核上做一次 load 微基准，看这台机器实测能达到多少内存带宽。这个实测上限比纸面上的理论带宽更有参考价值，之后你再看应用的内存带宽利用率才有一个合理基准。

第二轮分析的一个典型动作是：在应用最耗时的三个函数前后插上 marker，分别命名为 func_a、func_b、func_c，然后跑：

bash复制likwid-perfctr -C N0:0-15 -g CACHE -m ./app

输出中会分别列出每个标记区段的缓存未命中数、命中率、周期数。如果某个区段的 L3 命中率异常低，我会立刻去检查这个函数的数据访问 pattern 是不是存在大量稀疏跳转，或者临时数组是不是太大导致每次都绕过缓存。这种定位方式比拿 perf top 看符号热点更靠近微架构本质。

LIKWID 家族还有几个成员值得顺手了解：likwid-mpirun 前面提过，适合 MPI 环境；likwid-powermeter 可以单独读 RAPL 功耗，做功耗和性能的联合分析；likwid-setFreq 可以调节 CPU 频率，用来测频率对性能的影响。不过我实际项目里用得最多的还是拓扑、pin、perfctr 这三个，毕竟大多数性能问题的第一道关口就是“机器拓扑对不对、线程位置对不对、硬件计数器读数对不对”。

一点个人体会：使用 LIKWID 这几年，我最大的收获不是某个命令有多强，而是它让我养成了一种“先看拓扑再动手跑”的习惯。很多性能问题在绑核做完之后就已经消失了，根本不需要读到计数器；而真正需要计数器的时候，又往往是因为前面的拓扑分析已经帮你排除了几十种干扰因素。新到一个高性能计算节点，与其急着把应用跑起来，不如先花两分钟跑一遍 likwid-topology。这个习惯帮我省下的排查时间，远比记任何一个小技巧都划算。