作者：ciuwaalu，騰訊 TEG 后臺開發工程師

AMD 服務器，多線程應用綁核，選取不同的 CPU 核，性能差距可達50%。

最近有幸因項目拿到一臺?AMD EPYC 系列測試服務器，發現了一些奇怪的現象。

這臺測試服務器擁有雙路 AMD EPYC ?7552 ?處理器，屬于第二代 Rome（Zen2）架構，單路 48 個物理核，雙路總計 192 個邏輯核（線程），有兩個 NUMA 節點。

為了進行測試，預先編寫了一個簡單的多線程程序：

兩個線程，分別為生產者、消費者，模擬 route-worker 模型；

三個線程，分別為生產者、轉發者、消費者，模擬 pipeline 模型。

線程間采用無鎖隊列通信。生產者依次寫入 1 ~100000000，消費者取出數字求和。線程每次寫入或讀取隊列數據后執行一些無意義循環用于消耗時間，模擬業務邏輯。

所有線程分別綁核，避免線程遷移導致 Cache 抖動，且綁定的核心屬于同一個 CPU。所有隊列均在這個 CPU 的本地內存上進行分配，避免跨 NUMA 的遠程內存訪問。

奇怪的現象

測試發現，線程綁到不同的核上，有顯著的性能差異：

綁核說明：

核 #4 #5 #6 #8 #12 #100 均為同一個 CPU，不存在跨 NUMA 訪問內存的情況；

核 #4 #100 是一對 SMT 核心，即同一個物理核虛擬出來的兩個邏輯核；

黃條涉及的核 #48 屬于另一個 CPU，存在跨 NUMA 訪問內存的情況，僅供對比。

測試結果反映了一個很奇怪的現象：線程綁核，在同一個 NUMA 選取不同的核心，性能差距竟然達到 50%（route-worker 模型 #4#5 vs #4#8）甚至 140%（pipeline 模型 #4#5#6 vs #4#8#12）。

這究竟是為什么呢？

復雜的內存層次模型

這要從內存層次說起。通常，根據延遲時間從小到大，內存層次可以劃分為：（1）L1，一級緩存；（2）L2，二級緩存；（3）L3，又叫 LLC，三級緩存；（4）內存。

在具體實現上，傳統的 Intel 至強系列模型比較簡單：

• 每個物理核虛擬出兩個邏輯核（TR1/TR2，TR3/TR4）

• 每個物理核獨有 L1 和 L2

• 所有物理核共享 L3

這就解釋了一些高性能程序開發的優化策略：

• 避免跨 NUMA 的遠程內存訪問，除了降低訪問延遲，對 L3 也更友好

• 將線程綁核，避免 Cache 抖動，具體是避免 L1 和 L2 的抖動

• 共享 L3 的存在是透明的，軟件上不關心，也無法關心

這一切，在 AMD 的體系結構中發生了變化。

AMD 于 2017 年發布了 Zen 架構，其中一個重要的設計原則是：一塊 CPU 由多個 CCX（CPU Complex）堆疊而成。那么，CCX 是什么呢？簡單來說，CCX 實際上就是 4 個物理核（8 個邏輯核）+ L3。CCX 通過 IF 總線與 IO Die 連接（Rome），實現 CCX 間互通以及與內存、IO 的通信。

圖片來源：https://frankdenneman.nl/2019/10/14/amd-epyc-naples-vs-rome-and-vsphere-cpu-scheduler-updates/

所以，AMD EPYC 的內存模型就和傳統模型有了很大區別：L3 并不由所有物理核共享，而是由同一個 CCX 內的 4 個物理核共享。與 NUMA 引入的“遠程內存”概念類似，CCX 引入了“遠程 L3”的概念。

在網上找到一個訪問延遲表，供參考：

事件延遲

一個 CPU 周期（2.3GHz 主頻）	0.4 ns
訪問 L1	1.6 ns
訪問 L2	4.8 ns
訪問 L3	15.2 ns
訪問遠程 L3	63 ns
訪問本地內存	75 ns
訪問遠程內存	130 ns

結論與優化建議

結論是，在 AMD 服務器下，如果要獲得更高的性能，要針對 L3 進行優化，方法為：把一組任務（線程、進程）綁定到同一個 CCX 下的核心。

那怎樣才能知道哪些核心是同一個 CCX 呢？可以使用 hwloc-ls 命令：

可以看出：#0 #96 #1 #97 #2 #98 #3 #99 是 4 個物理核 8 個邏輯核，它們共享了 16 MB 的 L3，所以這幾個核屬于同一個 CCX。

因此，綁核的時候，可以綁 #0 #1 #2 #3 #96 #97 #98 #99，又或者 #4 #5 #6 #7 #100 #101 #102 #103，以此類推。

文章開頭的測試結果就很好解釋了：#4 #5 #6 是同一個 CCX，因為它們共享 L3，每次讀寫隊列其實都是讀寫 L3，所以性能高；#4 #8 #12 分屬 3 個不同的 CCX，每次寫隊列，都會使得其它 CCX 的 L3 數據失效，導致讀隊列時必須要從內存中讀取，所以性能差。

最后，可以通過：

perf stat -e r510143,r510243,r510843,r511043,r514043 ./xxx 查看 L3 的訪問情況，PMC Code 來自 AMD的官方文檔：

可以看到綁核 #4 #8 讀取內存次數幾乎是綁核 #4 #5 的 3 倍。

總結

以上是生活随笔為你收集整理的高性能编程：三级缓存（LLC）访问优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。