簡介LLCbench 是一套面向 Linux 平臺的低層表征基準測試工具集整合了 MPBench、CacheBench 與 BLASBench 三種測試方法此包取其中 CacheBench 部分用于衡量處理器各級緩存L1/L2/LLC的讀寫帶寬與訪問延遲適合體系結(jié)構(gòu)研究、服務(wù)器選型對比或性能調(diào)優(yōu)的開發(fā)者與高校師生使用。壓縮包共 81 個文件、約 83KB含 cachebench.c 等 C 源碼、Makefile 構(gòu)建腳本、llcbench.h 頭文件與 user.def 參數(shù)定義以及 sys.linux-mpich、sys.solaris、sys.ppc 等十余份平臺配置模板配合 doc 目錄下的 html/tex 說明文檔和 ps、gp 繪圖腳本可完成從編譯、跑分到結(jié)果出圖的完整流程。已有 873 人學習體量輕便解壓后按對應(yīng)平臺模板即可編譯驗證緩存帶寬與延遲表現(xiàn)。1. cachebench 這類跑緩存性能的工具很多人第一次接觸是從一份 llcbench.tar.gz 開始的包里幾個用 C 寫的 Linux 開源工具專做緩存層次和處理器性能測試。上周有人拿一臺二手工作站來問為什么同一份包在他的機器上編譯完cachebench 跑出來的 L3 帶寬比標稱值低將近一個數(shù)量級。我上去看scaling_governor還是powersave測試進程在 NUMA 節(jié)點間來回遷移工作集上限只設(shè)到 8 MB連 L3 都沒越過去。工具本身沒問題問題出在裝完就開跑。緩存測試對環(huán)境的敏感度比一般壓測高得多頻率、綁核、大頁、編譯器優(yōu)化等級任何一項沒配好出來的數(shù)字看著像結(jié)果實際是不可復現(xiàn)的噪聲。這篇裝的東西不復雜一份源碼包、一個 GCC、幾個內(nèi)核開關(guān)但順序和參數(shù)得對。2. 裝前先量體llcbench 的依賴清單與 GCC 工具鏈選型2.1 先用 lscpu 和 getconf 摸清這臺機器的緩存層級cachebench 的橫軸是工作集大小縱軸是訪存帶寬曲線上的臺階就是緩存邊界。你要是不知道這臺機器的 L1d、L2、LLC 各多大、LLC 是每個核心獨享還是整顆 CPU 共享那看到拐點也不知道對不對看到?jīng)]拐點也不知道是程序問題還是參數(shù)問題。所以裝之前先花兩分鐘把硬件底賬抄下來存檔留作后面判讀的依據(jù)。# 一次看清拓撲、緩存和 NUMA 節(jié)點數(shù) lscpu | grep -Ei model name|socket|core|thread|numa|cache # getconf 讀的是內(nèi)核導出的值和 lscpu 交叉驗證 getconf -a | grep -iE CACHE_SIZE|CACHE_LINE|CACHE_ASSOC # sysfs 里的 index 編號才是權(quán)威index0L1d, index2L2, index3LLC for i in /sys/devices/system/cpu/cpu0/cache/index*; do echo $i cat $i/level $i/type $i/size $i/shared_cpu_list done第一條命令里的socket和numa決定后面怎么綁核第二條的LEVEL1_DCACHE_SIZE、LEVEL3_CACHE_SIZE單位是字節(jié)用來給 cachebench 的-m參數(shù)定上限提供參考。最關(guān)鍵是第三條shared_cpu_list會告訴你 LLC 被哪些邏輯核共享比如輸出0-15說明這 16 個邏輯核共享同一個 LLC那測試時把進程綁到這 16 個核之外的任何一個訪存就要走跨片路徑帶寬數(shù)字會明顯掉一截。這一步做完本機的緩存地圖就有了順手記進一個hardware.txt以后換機器、換內(nèi)核版本都有對照。2.2 編譯依賴GCC、make、MPI、BLAS 哪些是必須的llcbench 這個包里通常不止一個可執(zhí)行程序cachebench 是純 C 加標準庫只需要 GCC 和 make要是你還想跑 mpbench就得有 MPI 的編譯包裝器mpiccblasbench 則要鏈接一個 BLAS 實現(xiàn)。很多人一上來把整條 MPI 棧、整套 BLAS 全拉下來裝完發(fā)現(xiàn)只是測個緩存白白多出幾十個包和一堆環(huán)境變量沖突。按需裝才是對的。組件版本要求Debian/Ubuntu 包名RHEL/Rocky 包名GCC7 以上913 都穩(wěn)build-essentialgcc、glibc-develmake4.xmakemakenumactl2.xnumactlnumactlcpupower需跟內(nèi)核版本對齊linux-tools-generickernel-toolsperf同上linux-tools-commonperfMPI可選OpenMPI 4.xlibopenmpi-dev、openmpi-binopenmpi-develOpenBLAS可選0.3.xlibopenblas-devopenblas-devel# 最小可用集只跑 cachebench 的話這一行就夠 sudo apt-get update sudo apt-get install -y build-essential make numactl linux-tools-common linux-tools-generic # 確實要跑 mpbench / blasbench 時再補這兩行 sudo apt-get install -y libopenmpi-dev openmpi-bin sudo apt-get install -y libopenblas-devRHEL 系把上面的包名換成表里右列即可注意dnf install openmpi-devel裝完mpicc落在/usr/lib64/openmpi/bin下默認不在 PATH 里得用module load mpi/openmpi-x86_64或者手動把那個目錄加進去否則which mpicc一無所獲。cpupower和perf一定要跟當前內(nèi)核同一個版本號版本錯位時 cpupower 會報Invalid argument之類的錯perf 則可能直接提示找不到符號這類問題九成是版本沒對齊而不是權(quán)限。2.3 解包與目錄規(guī)劃源碼別扔在 /root 下源碼目錄和結(jié)果目錄要分開而且最好不要放在家目錄。原因很實際測試前要清 page cache、要關(guān) swap跑完還會生成一堆 CSV 和日志混在/root里三個月后你自己都分不清哪份數(shù)據(jù)是哪臺機器的。我一般固定用/usr/local/src放源碼/opt/bench放二進制和結(jié)果。# 先看包里的頂層結(jié)構(gòu)確認解出來是單目錄還是散開的 tar -tzf llcbench.tar.gz | head -30 # 解到固定位置源碼保持只讀心態(tài)不在這里改 sudo mkdir -p /usr/local/src /opt/bench/bin sudo tar -xzf llcbench.tar.gz -C /usr/local/src cd /usr/local/src/llcbench ls -F第一條命令只是預覽確認壓縮包里是有一個頂層目錄還是文件直接鋪開鋪開的情況要加--one-top-level解到子目錄里否則幾十個文件撒進/usr/local/src很難收拾。第二條解完之后ls -F看看有哪些子目錄通常能看到和幾個模塊同名的目錄外加 Makefile 和說明文件。這時候先別急著make把gcc --version、uname -r、lscpu的摘要一起寫進/opt/bench/README.env以后復現(xiàn)結(jié)果全靠這份記錄。3. 編譯 cachebenchMakefile 目標選擇與 CFLAGS 取舍3.1 頂層 Makefile 的平臺目標怎么讀這類老牌 benchmark 包的頂層 Makefile 是手寫的平臺目標按操作系統(tǒng)命名Linux 下常見的是linux、linux-x86_64這兩種寫法年份不同、維護者不同目標名會變。直接make大多數(shù)情況會因為沒指定目標而只編譯第一個規(guī)則出來的東西未必是你想要的。先讀 Makefile 頭部比盲試快得多。cd /usr/local/src/llcbench # 看前 80 行平臺目標一般都在最上面 sed -n 1,80p Makefile # 看看有哪些 target 可選有 help 目標就省事了 make help 2/dev/null || grep -nE ^[a-zA-Z0-9_.-]: Makefile | head -40sed那一行是為了看清變量定義重點找CC、CFLAGS、ARCH這幾個它們決定編譯時實際傳了什么。第二條是退路老包不一定有help目標直接 grep 出所有規(guī)則名更實在。找到目標后按下面的方式傳參用命令行的CC/CFLAGS覆蓋掉 Makefile 里的默認值這是最不容易出錯的做法。# 用命令行變量覆蓋避免去改源碼里的 Makefile make CCgcc CFLAGS-O2 -fno-omit-frame-pointer -D_GNU_SOURCE linux-x86_64 # 換了目標或者改了 CFLAGS一定先 clean否則 .o 會復用 make clean make CCgcc CFLAGS-O2 -fno-omit-frame-pointer linux-x86_64CCgcc顯式指定編譯器是為了防止某些發(fā)行版把cc軟鏈到 clang編譯能過但生成的代碼特性不一樣。-O2是有意選的-O3會讓編譯器做更激進的循環(huán)展開和向量化訪問步長被改寫測出來的就不是你寫的那條訪存路徑了。-fno-omit-frame-pointer是給后面 perf 采樣留后路少了它調(diào)用棧會斷。clean那一步是血淚經(jīng)驗Makefile 的依賴關(guān)系經(jīng)常漏寫頭文件改了 CFLAGS 不 clean鏈接進去的還是舊目標文件你會以為參數(shù)沒生效。3.2 單模塊編譯繞過頂層 Makefile 更省事頂層目標對不上你的發(fā)行版時別跟 Makefile 較勁直接進模塊目錄編譯單文件。cachebench 是單文件程序一條 gcc 就能出二進制比調(diào)試 Makefile 快。先ls確認源文件名別照抄我這里的名字。cd /usr/local/src/llcbench/cachebench ls *.c # -O2 保持循環(huán)結(jié)構(gòu)-static 避免目標機 glibc 版本不一致-lm 是數(shù)學庫 gcc -O2 -fno-omit-frame-pointer -D_GNU_SOURCE \ -o cachebench cachebench.c -lm -static # 編完立刻驗證二進制能不能跑、依賴是否干凈 file cachebench ldd cachebench || echo static, no dynamic deps ./cachebench -h 21 | head -30參數(shù)逐個說清-D_GNU_SOURCE是為了讓clock_gettime、getopt_long這些接口在嚴格標準模式下也可見缺了它某些 glibc 版本會報隱式聲明。-lm一定要放在源文件后面鏈接器從左到右解析放前面會報undefined reference to sqrt。-static不是必須的但如果編譯機和測試機不是同一臺強烈建議加上動態(tài)鏈接的 glibc 版本差異會讓二進制在目標機上直接起不來。最后那條-h是必須做的不同年份的包cachebench 的命令行開關(guān)不完全一樣先看它自己打印的用法后面所有命令都按這個輸出調(diào)整別硬套別人的參數(shù)。3.3 mpbench 與 blasbench 的附加編譯參數(shù)這兩個模塊屬于“有就順手編沒有也不影響主流程”。mpbench 走 MPI編譯器和鏈接器都要換成mpiccblasbench 要鏈接 BLAS庫名在不同發(fā)行版上不一樣這是最容易卡住的地方。# mpbench用 mpicc 而不是 gcc頭文件和鏈接參數(shù)它自己帶 cd /usr/local/src/llcbench/mpbench ls *.c mpicc -O2 -o mpbench mpbench.c -lm # blasbench庫名按發(fā)行版二選一找不到就查一下 cd /usr/local/src/llcbench/blasbench gcc -O2 -o blasbench blasbench.c -lopenblas -lm # Debian 系也可能是 -lblasRHEL 上 OpenBLAS 常在 /usr/lib64/openblasmpicc本質(zhì)上是個包裝腳本會把 include 路徑和-lmpi都補上所以不要自作聰明改成gcc -lmpiOpenMPI 的庫路徑經(jīng)常不在默認搜索路徑里。blasbench 編譯失敗基本只有一種報錯undefined reference to dgemm_說明 BLAS 沒鏈上先ldconfig -p | grep -i blas看到底裝了哪個實現(xiàn)再決定用-lopenblas還是-lblas如果庫在非標準路徑補一個-L/usr/lib64/openblas。編完把三個二進制統(tǒng)一收進/opt/bench/bin源碼目錄就不再動了。install -m 0755 cachebench mpbench blasbench /opt/bench/bin/ 2/dev/null ls -l /opt/bench/bininstall -m 0755比cp更直接權(quán)限一步到位2/dev/null是容忍某個模塊沒編出來的情況比如你沒裝 MPImpbench 不存在不影響另外兩個。4. 讓數(shù)字可復現(xiàn)頻率、NUMA 與 THP 的三處配置4.1 頻率與 C-state別讓 CPU 在測試中自己降頻默認的powersave調(diào)速器會讓 CPU 頻率跟著負載浮動緩存帶寬和核心頻率強相關(guān)頻率一動同一段代碼跑兩次能差出三成。這不是玄學是電源管理在正常工作只是和測量的目標沖突。# 看當前策略和支持的策略 cpupower frequency-info | grep -E driver|governor|available cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor # 全部核心切到 performance sudo cpupower frequency-set -g performance # 關(guān)掉睿頻intel_pstate 和 acpi-cpufreq 路徑不同兩個都試 cat /sys/devices/system/cpu/intel_pstate/no_turbo 2/dev/null echo 1 | sudo tee /sys/devices/system/cpu/intel_pstate/no_turbo 2/dev/null echo 0 | sudo tee /sys/devices/system/cpu/cpufreq/boost 2/dev/null # 順帶把 C-state 限制到 C1避免深睡喚醒延遲污染小工作集的測量 sudo cpupower idle-set -D 1-g performance是把下限頂?shù)缴舷薮鷥r是功耗和溫度測試機上無所謂。關(guān)睿頻這一步經(jīng)常被忽略睿頻一開單核跑分時頻率會沖到標稱之上測出來的 L1 帶寬比理論值還高看著很爽但完全不可比。idle-set -D 1限制的是空閑狀態(tài)深度工作集只有幾十 KB 的時候CPU 大部分時間在等待緩存命中深 C-state 的進出延遲會體現(xiàn)在結(jié)果里。這幾條改的都是運行時狀態(tài)重啟即失效所以不用怕改壞但也意味著每次重啟后要重新執(zhí)行。4.2 NUMA 與綁核單線程跑分最怕遷移雙路機器上跨 NUMA 節(jié)點訪存的帶寬可能只有本地的一半多一點。cachebench 是單線程程序如果內(nèi)核調(diào)度器在測試過程中把它從這個節(jié)點挪到那個節(jié)點前半段和后半段測的根本不是同一塊內(nèi)存曲線會出現(xiàn)莫名其妙的抖動。# 先看清節(jié)點布局和每個節(jié)點的本地內(nèi)存大小 numactl -H # 綁到 0 號節(jié)點的 CPU 和內(nèi)存兩邊都鎖死 numactl --cpunodebind0 --membind0 /opt/bench/bin/cachebench -b -m 512 # 沒有 numactl 時至少把進程釘在某個核上 taskset -c 2 /opt/bench/bin/cachebench -b -m 512--cpunodebind管 CPU--membind管內(nèi)存分配兩個都要寫。只寫前者內(nèi)存仍可能從遠端節(jié)點分配測出來的帶寬照樣偏低。taskset -c 2是更輕量的替代只保證不遷移不保證內(nèi)存在本地適合已經(jīng)在 BIOS 里關(guān)掉節(jié)點交織的機器。判斷有沒有綁對跑的時候另開一個窗口執(zhí)行ps -o psr,comm -p $(pgrep cachebench)看PSR那一列是不是一直不變。4.3 大頁、swap 與 page cache把內(nèi)存?zhèn)鹊脑肼晧旱敉该鞔箜摃屚环莨ぷ骷袝r候落在 4K 頁、有時候落在 2M 頁頁表項數(shù)量和 TLB 命中率完全不同這就是同一臺機器兩次結(jié)果不一致的常見來源。測緩存的時候要的是確定性的頁行為寧可關(guān)掉。# 關(guān)閉 THP讓所有分配都走 4K 頁行為可預測 echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled echo never | sudo tee /sys/kernel/mm/transparent_hugepage/defrag # 關(guān)掉 NUMA balancing它會周期性掃描并遷移頁面 echo 0 | sudo tee /proc/sys/kernel/numa_balancing # 測試期間不需要 swap避免偶發(fā)換出拖慢大工作集那一段 sudo swapoff -a # 跑之前清一次 page cache保證大數(shù)組是真正的冷內(nèi)存 sync echo 3 | sudo tee /proc/sys/vm/drop_cachesdefrag那一項和enabled要一起關(guān)只關(guān)一個的情況下內(nèi)核仍可能為了湊大頁去做內(nèi)存整理表現(xiàn)為測試中途出現(xiàn)幾百毫秒的停頓。drop_caches寫 3 表示同時清 page cache、dentries 和 inodes需要 root且只在測試開始前執(zhí)行一次不要在循環(huán)里反復清那樣會把測量變成 IO 測試。4.4 一份可復用的測試前腳本與還原腳本上面這些零散命令每次手敲三遍必出錯。寫成兩個腳本一個負責進入測試態(tài)一個負責還原跑完一定執(zhí)行還原否則這臺機器后面跑什么都偏慢。#!/usr/bin/env bash # /opt/bench/prep.sh —— 進入測試態(tài)需要 root set -euo pipefail for f in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do [ -w $f ] echo performance $f # 逐核設(shè)置別指望一條命令全生效 done echo never /sys/kernel/mm/transparent_hugepage/enabled echo never /sys/kernel/mm/transparent_hugepage/defrag echo 0 /proc/sys/kernel/numa_balancing # 停止頁面自動遷移 swapoff -a || true # 已關(guān)時返回非零用 || true 兜住 sync echo 3 /proc/sys/vm/drop_caches echo [prep] done at $(date -Is)set -euo pipefail讓腳本在任一步失敗時立刻停下避免只配了一半還以為配好了。逐核寫scaling_governor而不是只用 cpupower是因為某些內(nèi)核上 cpupower 只改 policy 對象個別核心會被漏掉。|| true只加在swapoff上因為它對已關(guān)閉的 swap 會返回非零這是預期行為不該中斷腳本。#!/usr/bin/env bash # /opt/bench/restore.sh —— 還原跑完立刻執(zhí)行 set -uo pipefail for f in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do [ -w $f ] echo schedutil $f # 按發(fā)行版默認策略改ondemand 也行 done echo madvise /sys/kernel/mm/transparent_hugepage/enabled echo 1 /proc/sys/kernel/numa_balancing echo [restore] done at $(date -Is)還原腳本里沒去動 swap 和睿頻因為這兩項在多數(shù)生產(chǎn)機上本來就不該由測試腳本隨意改動手工確認更穩(wěn)妥。schedutil在較新內(nèi)核上是默認策略老內(nèi)核用ondemand改之前先看一眼/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors里有什么別寫一個不存在的策略名進去。5. 避坑排查llcbench 編譯與運行的五類翻車5.1 編譯期目標不存在和頭文件找不到現(xiàn)象一make linux-x86_64報No rule to make target。原因這份包的 Makefile 年代較早平臺目標命名和你猜的不一樣可能只寫了linux也可能要求通過變量傳架構(gòu)。解決grep -nE ^[a-z].*: Makefile把所有規(guī)則列出來照著用實在沒有匹配的放棄頂層 Makefile進模塊目錄按 3.2 節(jié)的方式單文件編譯兩分鐘的事別在這里耗?，F(xiàn)象二fatal error: mpi.h: No such file or directory但明明裝了 OpenMPI。原因openmpi-devel在 RHEL 系上裝到/usr/lib64/openmpi/頭文件和mpicc都不進默認搜索路徑。解決用mpicc編譯而不是gcc或者先module load mpi/openmpi-x86_64Debian 系一般沒這個問題因為libopenmpi-dev會把頭文件放進/usr/include。5.2 運行期段錯誤、全零輸出和虛高帶寬現(xiàn)象三二進制一跑就Segmentation fault編譯時毫無警告。原因老代碼里對long和指針寬度的假設(shè)在 64 位下不成立或者工作集上限-m給得太大、超過了容器或 cgroup 的內(nèi)存限制被 OOM killer 干掉。解決先dmesg | tail -20看有沒有 oom 記錄有就把-m降到物理內(nèi)存的六成以內(nèi)沒有就加-g重編一版用gdb ./cachebench跑出棧定位到具體行。現(xiàn)象四輸出表里所有尺寸的帶寬都是同一個數(shù)量級或者干脆全是 0。原因多半是編譯優(yōu)化過頭。-O3加上-marchnative時編譯器可能識別出循環(huán)里的訪存模式?jīng)]有副作用直接把整段消掉計時器測到的是一個空循環(huán)于是輸出一個巨大且平坦的值。解決退回-O2去掉-marchnativemake clean后重編。判斷是不是被優(yōu)化掉objdump -d cachebench | grep -c mfence之類的指令計數(shù)只是個參考最直接的辦法是看跑的時候top里 CPU 占用是不是接近 100%低于這個數(shù)基本可以確定循環(huán)沒真正執(zhí)行。5.3 結(jié)果期曲線沒拐點、兩次差三成現(xiàn)象五帶寬曲線是一條平滑下降的直線看不到 L1/L2/L3 的臺階。原因三條可能工作集上限-m太小沒越過 LLCTHP 沒關(guān)導致頁行為不一致把臺階抹平了或者進程每次都重新分配內(nèi)存、測的其實是頁錯誤開銷。解決把-m設(shè)成 LLC 容量的 816 倍比如 LLC 32 MB 就給-m 512確認第 4 章的腳本執(zhí)行過跑之前清一次 page cache。現(xiàn)象六同一臺機器、同一份二進制兩次跑差 30% 以上。原因頻率沒鎖、進程被調(diào)度到別的 NUMA 節(jié)點、或者機器上還有別的進程在搶 LLC。解決按 4.1 和 4.2 節(jié)鎖頻綁核跑之前ps aux --sort-%cpu | head確認沒有別的重負載兩次結(jié)果差異用標準差衡量綁核綁對了通常能壓到 3% 以內(nèi)壓不下去就說明還有別的東西在動。6. 裝完怎么驗證跑通三組數(shù)字對上了才算裝完裝完不等于跑通。判斷標準很簡單cachebench 的輸出、perf stat的計數(shù)、硬件的理論值這三組能互相解釋才算這套環(huán)境搭成功了。只看 cachebench 那一張表很容易被虛高的數(shù)字騙過去。先跑一遍基準把輸出存下來# -b 跑完整掃描-m 給到 LLC 的 8~16 倍-i 提高迭代次數(shù)降低抖動 /opt/bench/bin/cachebench -b -m 512 | tee /opt/bench/run-$(date %Y%m%d-%H%M).log看這張表只做三件事。第一找臺階從幾 KB 到幾十 KB 這一段應(yīng)該是最高帶寬越過 L1 掉一檔越過 L2 再掉一檔越過 LLC 掉到內(nèi)存水平臺階位置要和你 2.1 節(jié)抄下來的緩存尺寸對得上差一個數(shù)量級說明參數(shù)或環(huán)境有問題。第二看讀寫差異同尺寸下讀帶寬通常高于寫如果寫反而更高多半是寫路徑被編譯器優(yōu)化成了非臨時存儲回去檢查 CFLAGS。第三看尾部是否收斂工作集超過物理內(nèi)存的六成以后曲線應(yīng)該趨于平緩還在往下掉說明已經(jīng)在換頁了。再用 perf 交叉驗證一次確認測的就是緩存行為# perf_event_paranoid 太嚴會拒絕非 root 采樣先放開到 1 echo 1 | sudo tee /proc/sys/kernel/perf_event_paranoid # 只跑一個中等工作集看 LLC 命中率是否隨尺寸變化 sudo perf stat -e cycles,instructions,cache-references,cache-misses,LLC-loads,LLC-load-misses \ /opt/bench/bin/cachebench -b -m 512cache-misses除以cache-references得到的失效率應(yīng)該隨著工作集增大單調(diào)上升LLC-load-misses在越過 LLC 之后會明顯抬升。如果失效率從頭到尾是平的說明 perf 采樣到的和 cachebench 實際訪問的不是同一段內(nèi)存回頭檢查numactl有沒有寫錯節(jié)點。最后拿理論值對一下量級單通道 DDR 的實測帶寬通常在十幾 GB/s 這個量級L1 能到上百 GB/sL3 介于兩者之間實測值低于理論峰值三成以內(nèi)都算正常差一個數(shù)量級就別急著寫報告。觀察點正常表現(xiàn)異常時先查什么臺階位置與 lscpu 緩存尺寸一致-m上限、THP 是否關(guān)讀 vs 寫讀帶寬更高CFLAGS 是否-O3尾部收斂超過內(nèi)存六成后走平是否觸發(fā)換頁、-m過大perf 失效率隨工作集單調(diào)上升綁核、NUMA 節(jié)點從那以后我每次把 llcbench 解到一臺新機器上都強制先跑lscpu抄底賬、執(zhí)行一遍 prep 腳本鎖頻綁核、再用 perf 對一次失效率三步缺一步就不記錄數(shù)字。這個習慣救過我兩次一次是發(fā)現(xiàn)機器 BIOS 里睿頻根本沒關(guān)另一次是發(fā)現(xiàn)容器只給了 1 GB 內(nèi)存-m 512直接撞上了 cgroup 上限。希望幫到你。本文還有配套的精品資源點擊獲取