简介LLCbenchLow-Level Characterization Benchmarks是一套面向底层硬件性能表征的开源基准测试工具集整合了MPBench、CacheBench与BLASBench三类测试方法本资源聚焦其中的CacheBench模块用于评估处理器缓存读写、复制等关键性能指标。适合从事Linux系统调优、处理器架构研究及高性能计算方向的开发者与研究人员帮助定位缓存层级瓶颈、验证优化效果。压缩包共81个文件约83KB包含C源码、Makefile构建脚本、ps与gp绘图脚本、html说明文档、readme及tex技术文档并针对alpha、ppc、ia64、solaris、linux-mpich等多种平台提供配置模板便于跨环境编译运行。已有872人学习下载。借助完整的源码、构建脚本与结果可视化工具读者可快速搭建缓存性能测试环境理解CacheBench的测试原理与参数含义并结合绘图脚本生成直观的性能曲线为处理器选型与系统调优提供数据支撑。1. 一个压缩包名为什么值得单独写一篇llcbench.tar.gz这个文件名第一次看到的人大概率会愣一下llc 是 last level cachebench 是 benchmark合起来就是「末级缓存基准测试」。它不是一个能双击运行的软件也不是一个开箱即用的工具而是一类把 LLC 性能压到极限、逼出真实数字的测试工程打包。你如果正在做 CPU 微架构调优、NUMA 服务器选型、容器混部时的缓存干扰评估或者单纯想知道自己手里这台机器「缓存到底行不行」这个方向就绕不开。它解决的核心问题很具体厂商给的 LLC 容量、关联度、延迟都是标称值真实业务里多核争抢、跨 NUMA 访问、预取器行为叠加之后有效带宽和命中率可能差出一大截。llcbench这类工程的价值就是给你一套可复现的测量方法而不是让你对着 spec 表格猜。适合谁适合需要拿数据说话的性能工程师、系统软件开发者以及被「这台机器跑这个负载为什么慢」折磨过的运维同学。2. 拆开 llcbench它到底在测什么、怎么测2.1 LLC 基准测试的三个核心指标任何 LLC benchmark本质上都在回答三个问题延迟是多少、带宽有多大、争抢有多严重。延迟测试通常用指针追逐pointer chasing。构造一条链表每个节点指向下一个随机位置CPU 无法预取只能老老实实一次一次访存。当工作集大于 LLC 容量时测出来的是内存延迟当工作集刚好卡在 LLC 容量内测出来的就是 LLC 命中延迟。两者一减就能反推 LLC 的真实贡献。带宽测试则是让多个核心同时做流式读写观察总吞吐随核心数增长的曲线。单核带宽受限于单核的 miss 处理能力MSHR 数量多核之后才会逼近 LLC 和内存总线的上限。这条曲线的拐点往往就是系统真正的瓶颈位置。争抢测试更贴近生产一组核心跑「受害者」负载比如一个固定工作集的循环另一组核心跑「干扰者」负载大范围流式访问观察受害者性能掉了多少。这个掉幅就是混部场景下你最该关心的数字。2.2 从 tar.gz 到可运行解包与依赖检查拿到llcbench.tar.gz之后第一步不是急着编译而是先看清楚里面有什么。常见做法是先列目录树再读 README 和 Makefile确认依赖。# 解包到独立目录避免污染当前工作区 mkdir -p llcbench_work tar -xzf llcbench.tar.gz -C llcbench_work # 看目录结构重点关注 src/、scripts/、Makefile find llcbench_work -maxdepth 2 -type f | head -50 # 读构建说明确认编译器版本和依赖库 cat llcbench_work/*/README* 2/dev/null | head -60逻辑说明tar -xzf里的-z表示 gzip 解压-f指定文件-C指定目标目录。先find看结构而不是直接make是因为这类工程经常有多个子目录构建入口不一定在顶层。参数上-maxdepth 2防止目录太深刷屏head -50只是先扫一眼。依赖检查要盯三样编译器是否支持你需要的指令集比如 AVX2/AVX-512、是否有 pthread 或 OpenMP、是否需要 root 权限读 MSR 或 perf 事件。如果 README 里提到需要msr模块或perf_event_paranoid调整先记下来后面会用到。2.3 编译参数怎么选-O2 还是 -O3静态还是动态编译这一步参数选错测出来的数字就没有可比性。cd llcbench_work/*/src # 推荐-O2 保证不因过度优化改变访存模式-pthread 支持多线程 gcc -O2 -pthread -marchnative -o llcbench llcbench.c -lm # 如果工程用 Makefile先看默认 CFLAGS 再决定是否覆盖 make CFLAGS-O2 -pthread -marchnative -j$(nproc)逻辑说明-O2是基准测试的稳妥选择-O3有时会把指针追逐循环优化成你不想要的形式导致测的不是真实访存。-marchnative让编译器用上本机指令集但要注意——如果你打算把二进制拷到别的机器跑就别用native换成明确的-mavx2之类。-pthread是必须的LLC 争抢测试离不开多线程。-lm是数学库很多延迟统计会用到。参数说明-j$(nproc)让 make 并行编译nproc返回核心数。如果编译报错说找不到某个头文件先别改代码检查是不是缺了libnuma-dev之类的系统包。3. 跑出第一组可信数据工作集、线程数与绑核3.1 工作集大小怎么设从 1MB 到 1GB 的扫描策略工作集working set是 LLC benchmark 最关键的变量。设小了全在 L1/L2 里测不出 LLC设大了全在内存LLC 的影响被淹没。常见做法是做一次扫描从 1MB 开始按 2 倍递增到 1GB每个点跑固定轮数记录延迟和带宽。这样你能得到一条曲线曲线的平台区和拐点就是 LLC 的真实边界。# 扫描工作集从 1MB 到 1GB每档 2 倍递增 for size in 1 2 4 8 16 32 64 128 256 512 1024; do echo working set: ${size}MB ./llcbench --size ${size}M --threads 1 --iterations 1000000 --mode latency done逻辑说明--size控制工作集--threads 1先单线程排除干扰--iterations保证每个点有足够样本。--mode latency切到延迟模式。跑完把输出重定向到文件后面画图用。参数说明迭代次数不是越多越好太多会让总时间失控一般单点控制在几秒到十几秒。如果机器 LLC 是 32MB重点看 8MB 到 64MB 这一段拐点大概率在这里。3.2 线程数从 1 到物理核带宽曲线的拐点在哪单线程延迟测完接下来看带宽随线程数的变化。# 线程数从 1 递增到物理核心数测带宽 for t in 1 2 4 8 16 32; do echo threads: $t ./llcbench --size 256M --threads $t --iterations 500000 --mode bandwidth done逻辑说明工作集固定 256MB远大于典型 LLC确保测的是 LLC内存混合带宽。线程数递增观察总带宽。如果 8 线程之后带宽不再涨说明瓶颈已经从核心侧转移到 LLC 或内存侧。参数说明线程数不要超过物理核心数超线程核心跑带宽测试会引入额外噪声。如果机器有 NUMA先numactl --hardware看清楚节点分布再决定要不要绑核。3.3 绑核与 NUMA为什么你的数据总在抖数据抖动是 LLC benchmark 最常见的「玄学」问题。同一份代码跑两次差 20%大概率是调度和 NUMA 在作怪。# 绑到 0 号 NUMA 节点的 0-7 号核心 numactl --cpunodebind0 --membind0 ./llcbench --size 256M --threads 8 --mode bandwidth # 对比不绑核让调度器自由发挥 ./llcbench --size 256M --threads 8 --mode bandwidth逻辑说明--cpunodebind0把线程绑到 0 号节点的核心--membind0把内存分配也限制在 0 号节点避免跨节点访问。两次结果一对比就能看出 NUMA 影响有多大。参数说明如果numactl没装先装numactl包。绑核之后如果性能反而下降检查是不是绑到了超线程兄弟核上或者绑核范围太小导致线程排队。提示跑基准测试前把 CPU 调频策略设成 performance否则频率波动会直接污染延迟数据。命令是cpupower frequency-set -g performance需要 root。4. 避坑与排查那些让数据失真的细节4.1 现象延迟数据比 spec 高出一倍原因最常见的是工作集没对齐。你以为设了 32MB实际因为数据结构 padding 和页对齐真实占用可能是 40MB 以上早就溢出 LLC 了。另一个原因是没关预取器硬件预取把指针追逐的随机性抹掉了。解决先用--size从小往大扫找到延迟突变的那个点那才是真实 LLC 边界。预取器可以通过wrmsr关掉但更稳妥的做法是改用随机化步长让预取器失效。4.2 现象多线程带宽不升反降原因线程绑到了同一个物理核的超线程兄弟上两个线程抢同一个核的执行资源。或者 NUMA 跨节点访问带宽被互联总线卡住。解决用lscpu -e看清楚 CPU 和核心的映射关系绑核时跳过兄弟核。NUMA 场景下确保内存分配和计算在同一个节点。4.3 现象跑几分钟后数据突然变差原因温度墙或功耗墙触发降频。服务器长时间满载频率从标称掉到基频延迟自然涨。解决跑之前记录初始频率跑的过程中用turbostat或cpupower monitor观察频率变化。如果确实降频缩短单次测试时间或者接受这个数字——毕竟生产环境也会降频。4.4 现象容器里跑结果和宿主机差很多原因容器 CPU 配额限制、cgroup 调度干扰、或者容器内看不到真实拓扑。解决先确认容器是否绑定了固定 CPU 集--cpuset-cpus要和绑核参数一致。如果容器内lscpu看到的拓扑和宿主机不同以宿主机为准在容器启动时就把拓扑信息透传进去。4.5 现象编译报错说找不到 numa.h原因缺libnuma开发包。解决Debian 系装libnuma-devRHEL 系装numactl-devel。装完重新make clean make。5. 把 llcbench 用进真实决策从数字到结论5.1 用争抢测试评估混部密度前面测的都是「干净」环境下的极限值。真实生产里你更关心的是这台机器上再塞一个业务现有业务会掉多少。做法是跑两组进程一组是受害者固定工作集在 LLC 内循环另一组是干扰者逐步增加线程数做大范围流式访问。记录受害者吞吐随干扰者线程数的变化。# 终端 1启动受害者绑到 0-3 号核 numactl --cpunodebind0 --membind0 ./llcbench --size 16M --threads 4 --mode latency --tag victim # 终端 2启动干扰者绑到 4-7 号核线程数逐步增加 for t in 1 2 4; do numactl --cpunodebind0 --membind0 ./llcbench --size 512M --threads $t --mode bandwidth --tag干扰者 sleep 5 done逻辑说明受害者工作集 16MB假设 LLC 是 32MB它本来能安稳待在缓存里。干扰者工作集 512MB会把 LLC 大量挤出去。观察受害者延迟涨了多少就是混部的代价。参数说明--tag只是给输出打标签方便区分。两组进程绑到不同核心避免直接抢执行单元这样测出来的才是纯缓存争抢。5.2 不同 CPU 的 LLC 表现对比表如果你在选型可以把几台机器的关键数字拉一张表。下面是一个示例结构具体数字要自己跑。指标机器 A32MB LLC机器 B64MB LLC机器 C双 NUMA各 32MBLLC 命中延迟待测待测待测单核带宽待测待测待测全核带宽待测待测待测16MB 工作集争抢掉幅待测待测待测跨 NUMA 延迟惩罚不适用不适用待测这张表的价值在于容量大不一定全核带宽高NUMA 机器跨节点延迟可能直接翻倍。选型时把业务的实际工作集和并发模式代进去才能判断哪台更合适。5.3 一个容易忽略的技巧用 perf 交叉验证llcbench 给的是端到端数字perf 给的是硬件计数器视角。两者对不上说明中间有东西没考虑到。# 用 perf 统计 LLC miss 和 LLC load 事件 perf stat -e LLC-loads,LLC-load-misses,LLC-stores,LLC-store-misses \ ./llcbench --size 64M --threads 1 --mode latency逻辑说明LLC-loads是 LLC 加载次数LLC-load-misses是未命中次数两者相除就是命中率。如果 llcbench 报的延迟很高但 perf 显示命中率也很高那延迟高可能来自别的地方比如 TLB miss 或页表遍历。参数说明不同 CPU 的 perf 事件名可能略有差异用perf list | grep -i llc查一下本机支持哪些。如果权限不够调整perf_event_paranoid或直接用 root。我自己踩过最狠的一次坑是拿一台没关预取器的机器测 LLC 延迟数据漂亮得不像话差点据此写了选型报告。后来换了个随机化步长的版本重测数字直接翻倍。从那以后我养成了一个习惯任何基准测试先用两种独立方法交叉验证对不上就先怀疑测量方法别急着下结论。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/14 12:24:49 · 阅读 1.2k LLC基准测试实战：从llcbench解包到NUMA绑核与混部争抢评估
简介LLCbenchLow-Level Characterization Benchmarks是一套面向底层硬件性能表征的开源基准测试工具集整合了MPBench、CacheBench与BLASBench三类测试方法本资源聚焦其中的CacheBench模块用于评估处理器缓存读写、复制等关键性能指标。适合从事Linux系统调优、处理器架构研究及高性能计算方向的开发者与研究人员帮助定位缓存层级瓶颈、验证优化效果。压缩包共81个文件约83KB包含C源码、Makefile构建脚本、ps与gp绘图脚本、html说明文档、readme及tex技术文档并针对alpha、ppc、ia64、solaris、linux-mpich等多种平台提供配置模板便于跨环境编译运行。已有872人学习下载。借助完整的源码、构建脚本与结果可视化工具读者可快速搭建缓存性能测试环境理解CacheBench的测试原理与参数含义并结合绘图脚本生成直观的性能曲线为处理器选型与系统调优提供数据支撑。1. 一个压缩包名为什么值得单独写一篇llcbench.tar.gz这个文件名第一次看到的人大概率会愣一下llc 是 last level cachebench 是 benchmark合起来就是「末级缓存基准测试」。它不是一个能双击运行的软件也不是一个开箱即用的工具而是一类把 LLC 性能压到极限、逼出真实数字的测试工程打包。你如果正在做 CPU 微架构调优、NUMA 服务器选型、容器混部时的缓存干扰评估或者单纯想知道自己手里这台机器「缓存到底行不行」这个方向就绕不开。它解决的核心问题很具体厂商给的 LLC 容量、关联度、延迟都是标称值真实业务里多核争抢、跨 NUMA 访问、预取器行为叠加之后有效带宽和命中率可能差出一大截。llcbench这类工程的价值就是给你一套可复现的测量方法而不是让你对着 spec 表格猜。适合谁适合需要拿数据说话的性能工程师、系统软件开发者以及被「这台机器跑这个负载为什么慢」折磨过的运维同学。2. 拆开 llcbench它到底在测什么、怎么测2.1 LLC 基准测试的三个核心指标任何 LLC benchmark本质上都在回答三个问题延迟是多少、带宽有多大、争抢有多严重。延迟测试通常用指针追逐pointer chasing。构造一条链表每个节点指向下一个随机位置CPU 无法预取只能老老实实一次一次访存。当工作集大于 LLC 容量时测出来的是内存延迟当工作集刚好卡在 LLC 容量内测出来的就是 LLC 命中延迟。两者一减就能反推 LLC 的真实贡献。带宽测试则是让多个核心同时做流式读写观察总吞吐随核心数增长的曲线。单核带宽受限于单核的 miss 处理能力MSHR 数量多核之后才会逼近 LLC 和内存总线的上限。这条曲线的拐点往往就是系统真正的瓶颈位置。争抢测试更贴近生产一组核心跑「受害者」负载比如一个固定工作集的循环另一组核心跑「干扰者」负载大范围流式访问观察受害者性能掉了多少。这个掉幅就是混部场景下你最该关心的数字。2.2 从 tar.gz 到可运行解包与依赖检查拿到llcbench.tar.gz之后第一步不是急着编译而是先看清楚里面有什么。常见做法是先列目录树再读 README 和 Makefile确认依赖。# 解包到独立目录避免污染当前工作区 mkdir -p llcbench_work tar -xzf llcbench.tar.gz -C llcbench_work # 看目录结构重点关注 src/、scripts/、Makefile find llcbench_work -maxdepth 2 -type f | head -50 # 读构建说明确认编译器版本和依赖库 cat llcbench_work/*/README* 2/dev/null | head -60逻辑说明tar -xzf里的-z表示 gzip 解压-f指定文件-C指定目标目录。先find看结构而不是直接make是因为这类工程经常有多个子目录构建入口不一定在顶层。参数上-maxdepth 2防止目录太深刷屏head -50只是先扫一眼。依赖检查要盯三样编译器是否支持你需要的指令集比如 AVX2/AVX-512、是否有 pthread 或 OpenMP、是否需要 root 权限读 MSR 或 perf 事件。如果 README 里提到需要msr模块或perf_event_paranoid调整先记下来后面会用到。2.3 编译参数怎么选-O2 还是 -O3静态还是动态编译这一步参数选错测出来的数字就没有可比性。cd llcbench_work/*/src # 推荐-O2 保证不因过度优化改变访存模式-pthread 支持多线程 gcc -O2 -pthread -marchnative -o llcbench llcbench.c -lm # 如果工程用 Makefile先看默认 CFLAGS 再决定是否覆盖 make CFLAGS-O2 -pthread -marchnative -j$(nproc)逻辑说明-O2是基准测试的稳妥选择-O3有时会把指针追逐循环优化成你不想要的形式导致测的不是真实访存。-marchnative让编译器用上本机指令集但要注意——如果你打算把二进制拷到别的机器跑就别用native换成明确的-mavx2之类。-pthread是必须的LLC 争抢测试离不开多线程。-lm是数学库很多延迟统计会用到。参数说明-j$(nproc)让 make 并行编译nproc返回核心数。如果编译报错说找不到某个头文件先别改代码检查是不是缺了libnuma-dev之类的系统包。3. 跑出第一组可信数据工作集、线程数与绑核3.1 工作集大小怎么设从 1MB 到 1GB 的扫描策略工作集working set是 LLC benchmark 最关键的变量。设小了全在 L1/L2 里测不出 LLC设大了全在内存LLC 的影响被淹没。常见做法是做一次扫描从 1MB 开始按 2 倍递增到 1GB每个点跑固定轮数记录延迟和带宽。这样你能得到一条曲线曲线的平台区和拐点就是 LLC 的真实边界。# 扫描工作集从 1MB 到 1GB每档 2 倍递增 for size in 1 2 4 8 16 32 64 128 256 512 1024; do echo working set: ${size}MB ./llcbench --size ${size}M --threads 1 --iterations 1000000 --mode latency done逻辑说明--size控制工作集--threads 1先单线程排除干扰--iterations保证每个点有足够样本。--mode latency切到延迟模式。跑完把输出重定向到文件后面画图用。参数说明迭代次数不是越多越好太多会让总时间失控一般单点控制在几秒到十几秒。如果机器 LLC 是 32MB重点看 8MB 到 64MB 这一段拐点大概率在这里。3.2 线程数从 1 到物理核带宽曲线的拐点在哪单线程延迟测完接下来看带宽随线程数的变化。# 线程数从 1 递增到物理核心数测带宽 for t in 1 2 4 8 16 32; do echo threads: $t ./llcbench --size 256M --threads $t --iterations 500000 --mode bandwidth done逻辑说明工作集固定 256MB远大于典型 LLC确保测的是 LLC内存混合带宽。线程数递增观察总带宽。如果 8 线程之后带宽不再涨说明瓶颈已经从核心侧转移到 LLC 或内存侧。参数说明线程数不要超过物理核心数超线程核心跑带宽测试会引入额外噪声。如果机器有 NUMA先numactl --hardware看清楚节点分布再决定要不要绑核。3.3 绑核与 NUMA为什么你的数据总在抖数据抖动是 LLC benchmark 最常见的「玄学」问题。同一份代码跑两次差 20%大概率是调度和 NUMA 在作怪。# 绑到 0 号 NUMA 节点的 0-7 号核心 numactl --cpunodebind0 --membind0 ./llcbench --size 256M --threads 8 --mode bandwidth # 对比不绑核让调度器自由发挥 ./llcbench --size 256M --threads 8 --mode bandwidth逻辑说明--cpunodebind0把线程绑到 0 号节点的核心--membind0把内存分配也限制在 0 号节点避免跨节点访问。两次结果一对比就能看出 NUMA 影响有多大。参数说明如果numactl没装先装numactl包。绑核之后如果性能反而下降检查是不是绑到了超线程兄弟核上或者绑核范围太小导致线程排队。提示跑基准测试前把 CPU 调频策略设成 performance否则频率波动会直接污染延迟数据。命令是cpupower frequency-set -g performance需要 root。4. 避坑与排查那些让数据失真的细节4.1 现象延迟数据比 spec 高出一倍原因最常见的是工作集没对齐。你以为设了 32MB实际因为数据结构 padding 和页对齐真实占用可能是 40MB 以上早就溢出 LLC 了。另一个原因是没关预取器硬件预取把指针追逐的随机性抹掉了。解决先用--size从小往大扫找到延迟突变的那个点那才是真实 LLC 边界。预取器可以通过wrmsr关掉但更稳妥的做法是改用随机化步长让预取器失效。4.2 现象多线程带宽不升反降原因线程绑到了同一个物理核的超线程兄弟上两个线程抢同一个核的执行资源。或者 NUMA 跨节点访问带宽被互联总线卡住。解决用lscpu -e看清楚 CPU 和核心的映射关系绑核时跳过兄弟核。NUMA 场景下确保内存分配和计算在同一个节点。4.3 现象跑几分钟后数据突然变差原因温度墙或功耗墙触发降频。服务器长时间满载频率从标称掉到基频延迟自然涨。解决跑之前记录初始频率跑的过程中用turbostat或cpupower monitor观察频率变化。如果确实降频缩短单次测试时间或者接受这个数字——毕竟生产环境也会降频。4.4 现象容器里跑结果和宿主机差很多原因容器 CPU 配额限制、cgroup 调度干扰、或者容器内看不到真实拓扑。解决先确认容器是否绑定了固定 CPU 集--cpuset-cpus要和绑核参数一致。如果容器内lscpu看到的拓扑和宿主机不同以宿主机为准在容器启动时就把拓扑信息透传进去。4.5 现象编译报错说找不到 numa.h原因缺libnuma开发包。解决Debian 系装libnuma-devRHEL 系装numactl-devel。装完重新make clean make。5. 把 llcbench 用进真实决策从数字到结论5.1 用争抢测试评估混部密度前面测的都是「干净」环境下的极限值。真实生产里你更关心的是这台机器上再塞一个业务现有业务会掉多少。做法是跑两组进程一组是受害者固定工作集在 LLC 内循环另一组是干扰者逐步增加线程数做大范围流式访问。记录受害者吞吐随干扰者线程数的变化。# 终端 1启动受害者绑到 0-3 号核 numactl --cpunodebind0 --membind0 ./llcbench --size 16M --threads 4 --mode latency --tag victim # 终端 2启动干扰者绑到 4-7 号核线程数逐步增加 for t in 1 2 4; do numactl --cpunodebind0 --membind0 ./llcbench --size 512M --threads $t --mode bandwidth --tag干扰者 sleep 5 done逻辑说明受害者工作集 16MB假设 LLC 是 32MB它本来能安稳待在缓存里。干扰者工作集 512MB会把 LLC 大量挤出去。观察受害者延迟涨了多少就是混部的代价。参数说明--tag只是给输出打标签方便区分。两组进程绑到不同核心避免直接抢执行单元这样测出来的才是纯缓存争抢。5.2 不同 CPU 的 LLC 表现对比表如果你在选型可以把几台机器的关键数字拉一张表。下面是一个示例结构具体数字要自己跑。指标机器 A32MB LLC机器 B64MB LLC机器 C双 NUMA各 32MBLLC 命中延迟待测待测待测单核带宽待测待测待测全核带宽待测待测待测16MB 工作集争抢掉幅待测待测待测跨 NUMA 延迟惩罚不适用不适用待测这张表的价值在于容量大不一定全核带宽高NUMA 机器跨节点延迟可能直接翻倍。选型时把业务的实际工作集和并发模式代进去才能判断哪台更合适。5.3 一个容易忽略的技巧用 perf 交叉验证llcbench 给的是端到端数字perf 给的是硬件计数器视角。两者对不上说明中间有东西没考虑到。# 用 perf 统计 LLC miss 和 LLC load 事件 perf stat -e LLC-loads,LLC-load-misses,LLC-stores,LLC-store-misses \ ./llcbench --size 64M --threads 1 --mode latency逻辑说明LLC-loads是 LLC 加载次数LLC-load-misses是未命中次数两者相除就是命中率。如果 llcbench 报的延迟很高但 perf 显示命中率也很高那延迟高可能来自别的地方比如 TLB miss 或页表遍历。参数说明不同 CPU 的 perf 事件名可能略有差异用perf list | grep -i llc查一下本机支持哪些。如果权限不够调整perf_event_paranoid或直接用 root。我自己踩过最狠的一次坑是拿一台没关预取器的机器测 LLC 延迟数据漂亮得不像话差点据此写了选型报告。后来换了个随机化步长的版本重测数字直接翻倍。从那以后我养成了一个习惯任何基准测试先用两种独立方法交叉验证对不上就先怀疑测量方法别急着下结论。希望帮到你。本文还有配套的精品资源点击获取