llcbench实战：从tar.gz到精准定位缓存与访存瓶颈

简介llcbench.tar.gz 是一套基于 LLCbenchLow-Level Characterization Benchmarks的处理器缓存性能测试资源包面向系统性能优化工程师、嵌入式开发者以及有一定 C 语言和 Linux 基础的研究人员用于度量缓存命中率、失效延迟等关键指标。该工具集成了 MPBench、CacheBench 与 BLASBench 三种测试方法并专注于其中的 CacheBench 缓存基准测试可在常见 Linux 发行版上直接编译运行。压缩包共含 81 个文件体积仅 83KB主要文件类型包括 C 源码、Makefile 构建脚本、Gnuplot 绘图脚本、HTML 文档、README 说明以及 alpha、ppc、solaris、linux-mpich 等多种体系结构的配置文件。其中 C 源码是基准测试的核心实现Makefile 负责自动化编译Gnuplot 脚本可将结果绘制为图表便于直观分析缓存行为目前已有 869 人学习使用。借助这份压缩包读者可以获得 CacheBench 完整源码、可移植的构建配置、结果绘图模板以及不同处理器平台的 sys.def 参数文件可快速搭建缓存性能测试环境并输出可视化结果也可据此扩展至 MPI 集群下的性能评测。 同事扔给我一个llcbench.tar.gz让我在这台新到的服务器上跑一遍看看是哪个部件拖了后腿。我看了一眼文件名心里先打了个问号llcbench这个快三十年的老牌基准测试套件现在还有人拿它干活不过任务摆在眼前我也只能老实解压、编译、跑起来。一圈折腾完之后我发现这个看起来特别“复古”的压缩包在定位缓存层级和访存瓶颈这件事上居然比很多新式工具都更锋利。如果你手里也拿到过这么个tar.gz想知道里面装的是什么、去哪儿编译、跑出来的表格怎么读那这篇就是给你写的。没有高深分析全是命令行实测记录外加我踩过的几个坑。1. 先搞清楚llcbench这个包到底在测什么1.1 一个压缩包两套完全不同的benchmarkllcbench全称是Low Level Characterization Benchmark我记不清最早是谁把它打成tar.gz分发出来的但它的代码结构和说明文档都带着上世纪科研项目的痕迹没那么多花哨依赖逻辑直接一个压缩包里面装了两套相对独立的东西。第一套叫CacheBench干的是对单台机器的内存子系统做底层刻画想尽办法测出L1、L2、L3各级缓存的容量、行大小、访问延迟以及内存控制器配合主存时给出的最终延迟。第二套叫MPBench是MPI编程模型下的微基准测并行程序里最常出现的点对点通信和集合通信开销比如常见的Allreduce、Bcast、Alltoall这类操作。这两个东西被放在同一个包里背后是同一类使用场景HPC集群和并行计算。CacheBench解决“单节点到底能吃多少内存带宽、访存延迟是否达标”MPBench解决“多节点之间消息传递要花多少时间、消息从短到长时延迟和带宽的拐点在哪里”。现在的超算验收、服务器选型、甚至云厂商给的实例规格确认问到底还是这两个问题。1.2 什么人会需要它说直白点需要回答“这台机器是否发挥出了设计性能”的人都应该在工具箱里留一份llcbench。比如我是做系统性能分析的新机器到货后没时间听厂商吹参数直接解压编译跑一个CacheBench两个小时之内就能看到一组接近芯片白皮书的数据。如果实测L3延迟比标称值高出一倍那基本就是NUMA策略、远程内存分配或者BIOS里某些节能选项出了岔子。做科学计算的用户也会需要它。矩阵运算、稀疏求解、差分模拟这类负载本质上是把内存里的数据反复搬进CPU能不能吃满内存带宽直接决定算得完还是算不完。CacheBench给出的访存延迟和有效带宽数据可以帮你判断要不要调进程绑核、改MPI通信拓扑。MPBench则适合并行中间件开发、MPI库调优、高速网络选型的人跑一次就能看到不同消息大小下的延迟曲线。1.3 跟sysbench、lmbench这类常用工具的区别有人会问sysbench不是也能测内存吗为什么非要用llcbenchsysbench的设计目标是用尽可能接近业务的方式压测资源它测出来的内存带宽是比较“宏观”的带了一定随机访问和业务模拟的成分。而CacheBench要的是“特征值”它把工作集尺寸从几千字节一路涨到十几甚至几十兆字节然后把每一档的平均访存时间记下来从这条时间曲线里直接反推出缓存层级。lmbench其实和它定位有点像也能测内存延迟、文件系统、上下文切换等。但CacheBench的专注点更极端它只盯着缓存和主存这条通路跑。一旦你的目标是分析访存时间曲线、找缓存容量拐点CacheBench比lmbench更顺手。后面我会用实测数据说明这个“拐点”长什么样。2. 理解CacheBench的测量逻辑动手才有意义2.1 访存延迟分层拐点就是容量CacheBench的核心逻辑一句话就能讲完以不同的数组大小反复访问内存记录每次访问的平均时间。现代CPU的内存访问不是按字节直接去主存找而是先查L1缓存没命中再看L2再没命中看L3最后才落到主存。每一层访问一次的成本差别非常悬殊比如L1命中可能只要4个时钟周期一次L2访问可能是十几个周期L3又是几十个周期而一次主存访问可能要上百个周期。几十倍的差距放在时间轴上就是一道明显的坎。当测试用的数组大小为2KB、4KB数据全被L1和L2装下平均访存时间会维持在一个很低的平台。当数组继续变大超过了L1容量开始大量触发L2访问时间会往上涨一次等到数组大到连L2甚至L3都装不下需要反复回主存拿数据时间会再跳一次。所以CacheBench输出的一张表里你能看到好几个“台阶”每个台阶的起点对应的就是某一级缓存的容量边界。这就是我前面说的拐点。2.2 步长参数决定的是Cache Line大小除了容量CacheBench还能测缓存行大小。缓存不是按单个字节管理的而是按缓存行常见的行大小是64字节或者128字节。测试时改变访问步长从1字节、16字节、64字节、128字节、256字节这样往上跳能观察到同一个数组大小下平均访存时间出现明显变化的位置那个位置基本就是缓存行边界。有经验的工程师拿到CacheBench的完整一组结果能直接报出“这台的L1是32KB8路组相联行大小64字节”这些数值拿去跟处理器白皮书对上比对质保书还实在。我自己看结果时就养成了一个习惯先不看厂商参数直接从输出的阶梯位置反推容量再用lscpu核对这一步能快速判断测试环境有没有被虚拟化或者容器隔离扭曲。2.3 它靠“循环压时间”来拿到稳读数为了拿到有统计意义的读数CacheBench不是访问一次数组就收工而是会做很多次重复访问再把总耗时除以访问次数得到单次平均时间。数组小的时候循环次数会被放得非常大保证计时有精度数组大到一定程度它会减少循环次数避免一次测试浪费太多时间。很多版本的CacheBench支持用户自己指定时间上限或者循环次数方便在慢速机器上灵活调整。它调用的是系统的高精度计时接口输出精度能到纳秒甚至更细有些版本还会顺手折算成时钟周期。这里有个细节要注意访问模式会明显影响结果顺序访问和随机访问测出来的绝对数值差别很大所以对比数据时必须确认两次测试用的是同一类访问模式。3. 从tar.gz到结果完整跑通一遍3.1 解压后的旧式目录结构拿到llcbench.tar.gz之后第一步自然是解压。命令没什么新鲜的tar -xzf llcbench.tar.gz cd llcbench ls你会看到它保持着早期科研代码的布局README、Makefile、benchmarks目录、config目录、scripts目录。没有现在动辄几万个文件的依赖体系东西也不分层十几秒就完整展开。README里会告诉你作者是谁、依赖什么编译器、推荐用什么系统跑非常老派但信息密度很高。我建议你先把README扫一遍特别是版本描述里的已知问题部分那比网上道听途说可靠得多。3.2 configure和make阶段怎么处理MPI依赖编译之前先处理依赖。CacheBench部分只需要C/Fortran编译器MPBench部分则需要MPI环境。我的操作是./configure如果你系统里装了gcc和OpenMPI或者MPICHconfigure多半能顺路认出mpicc。如果它没认出来也不要慌这不是死路你完全可以只make CacheBench那部分跳过MPBench或者显式指定MPI编译器的路径。configure本质上只是生成一个Makefile片段把CC、MPICC、CFLAGS这些变量填好并不是什么黑魔法。我记得第一次编译时configure在检测MPI的步骤上卡了一会我直接看了一眼它生成的配置文件手动把MPICC指到/usr/bin/mpicc就过了。整个过程最耗时间的反而是make时去翻各种头文件路径。3.3 跑脚本时的实际输出长什么样make之后benchmarks目录下会多出几个可执行文件CacheBench的可执行文件通常叫cache_gr、cache_wr之类的名字。运行脚本也有现成封装不同脚本对应不同的观测目标./runme_l1 ./runme_l2 ./runme_l3 ./runme_cachesize我在一台测试机上跑runme_cachesize时屏幕上会直接打出一张ASCII表格一列是数组大小一列是平均访存时间时间单位是纳秒但也有的版本直接按时钟周期输出。表格不需要美化一眼就能看出趋势。MPBench部分我一般这样跑mpirun -np 2 ./runme_mpiMPI环境的版本差异比较大这里不展开细节但基本套路一致先起好并行环境再指定进程数最后把微基准程序丢进去。4. 结果怎么读才不算白跑4.1 一条延时曲线上有两个明显的台阶读结果最直接的办法是画图。把数组大小作为横轴建议用对数坐标平均访存时间作为纵轴你会看到一条典型的阶梯曲线。以我最近一次测试为例当数组在2MB以内平均访问时间始终压在几十纳秒级别一旦数组超过4MB时间猛然跳到一百纳秒开外再往后还有一个更高的平台期说明当前这台机器L3容量就在4MB到8MB这个量级之间。如果你手头没有画图工具直接看表格也一样那一列时间在最开始的小数组区间几乎是一条平线中间某个位置开始持续抬升之后又变平。只要找到两次抬升对应的横坐标缓存层级容量就已经写在脸上了。4.2 横向对比机器时读数规则要统一横向对比机器时最关键的规则是“保证同样的参数、同样的编译器、同样的优化级别、同样的绑核策略”。千万不要在一台机器上用默认参数另一台上用自定义的数组序列。llcbench对参数非常敏感任何尺寸序列上的差异都会把拐点位置模糊掉。我见过有人拿两组数据对比最后发现其中一组根本没跑超L2那一档结论自然全偏了。还有编译器优化级别用-O0和-O3跑出来的结果会差一截对比时必须统一。如果你要写进报告或者PPT把运行命令和系统环境一并贴出来这是业内人士看数据的底线。4.3 频率锁定、NUMA、后台负载都是干扰源跑的时候要把系统环境稳住。最典型的干扰源有三个CPU动态调频、NUMA内存分配、后台任务。动态调频会直接改变每周期时间尤其在云主机和笔记本上频率忽高忽低测出来的延迟曲线可能到处都是锯齿。NUMA则影响远程内存访问一个被调度到Node0的进程如果数组内存落在Node1上延迟会莫名高出一截那测出来的就不是单机性能而是跨NUMA节点的通信性能。后台任务的干扰就更直接了我建议跑测试前用top或者htop确认负载为个位数必要时关掉不相关服务。5. 几轮实测之后总结的注意事项5.1 跑之前先把CPU绑死跑之前把CPU绑死。具体做法是taskset配合numactl一起用numactl --physcpubind2 --membind0 ./runme_cachesize或者至少用taskset -c 2保证进程不会从某个核飘到另一个核。频率这块直接在BIOS里锁死P-state最省心如果没权限改BIOS可以临时用cpupower把governor调成performance跑完再改回来。我第一次跑的时候偷懒没绑核结果两轮数据差出15%以上后来把进程钉死在一个物理核上才稳定。这是个方向上完全正确、操作上却极容易被忽略的细节。5.2 别把公开脚本里的默认参数照单全收不同版本llcbench的runme脚本里默认的数组范围可能定得很保守只适合当年的CPU。现在服务器动不动就几十MB、上百MB的L3缓存默认参数很可能根本触及不到“主存平台”那一档。这时需要自己把数组序列往大扩展比如从2MB一直延伸到64MB、128MB确保拐点完整出现。数组上限设太高也有问题耗时会拉长所以要找到一个平衡点。我的习惯是先快速跑一遍小序列预估缓存容量再针对性扩展范围精测。5.3 只有CacheBench需求的可以不理会MPI如果纯粹为了看缓存容量完全可以不碰MPI的东西。CacheBench是单进程程序不依赖mpirun很多初次接触的人被configure里关于MPI的问题吓到其实完全不用管。单独编译cache_gr然后直接运行CacheBench照样出结果。这一点对临时排查问题特别有用。有一次我在一台没有MPI环境的机器上想快速评估内存性能直接tar解压、make cache相关目标、运行全程没装任何MPI库十分钟出数据。5.4 不要拿它当应用层性能预告还有一点容易误用CacheBench测试的是底层硬件的理论边界不是你的业务程序性能。它告诉你“这台机器访存延迟是正常的”但你的业务程序依然可能跑得慢因为瓶颈可能出在算法局部性差、锁竞争、I/O等待上。llcbench的角色是硬件体检报告不是应用性能预告。这块边界拿捏住后面排查问题时就不会被带偏。我自己就有过教训看到CacheBench数据很正常就以为业务代码没问题结果一查发现是磁盘路径上的一次多余拷贝拖垮了整体吞吐跟缓存半毛钱关系没有。这次折腾llcbench.tar.gz过程不长但收获不小。最值钱的是让“缓存层级”这个抽象概念变成眼前一张清晰的阶梯表格。后来再做性能分析我也习惯先花一个小时跑CacheBench把机器的内存行为基线铺好再谈代码优化。如果你的任务跟HPC、服务器选型、底层性能验证沾边建议你把那个躺在角落不知道多久的tar.gz解压出来重新跑一次它带给你的信息量可能比最新框架还实在。本文还有配套的精品资源点击获取