作者：安謀科技 (Arm China) 主任軟件工程師 常瑞

Arm Neoverse N 系列和 V 系列處理器并未采用同步多線程 (SMT) 技術。在 Arm Neoverse 處理器上運行時，每個線程始終能夠訪問處理器的全部資源。這有助于提高在云環境中執行的可預測性，確保每個線程都能完全訪問處理器資源，并提供更強大的保護，防止線程之間發生意外數據泄露。

在采用 SMT 技術的處理器中，每個物理處理器分為兩個或兩個以上的邏輯核心。這些邏輯核心相互共享一些資源。例如，一種常見的設計是，邏輯核心共享執行單元，分支預測器、預取器和緩存等處理器結構。在 SMT 系統中，每個邏輯核心都有自己的寄存器和程序計數器，因此每個邏輯核心能夠執行獨立的執行線程。市面上典型的 SMT 實現方案包括英特爾的超線程 (Hyper-Threading) 和 AMD 的 SMT。

如果比較 Neoverse 處理器和其他支持 SMT 的處理器的 CPU 使用率，有時會出現這樣的情況：在類似的輕負載水平下，Arm CPU 使用率似乎更高。這可能令使用者認為 Arm 平臺的性能可用擴展空間較小。在本文中，我們將探討輕負載場景下，比較采用 SMT 和未采用 SMT 的系統時，為什么“CPU 使用率”指標可能具有誤導性。

測量 CPU 使用率

Linux 操作系統根據 CPU 核心在工作還是處于空閑狀態來計算 CPU 使用率。SMT 模式下的邏輯核心共享物理核心的執行資源。在輕負載場景下，邏輯核心能夠以物理核心的能力全速運行。因此，操作系統可能會顯示邏輯 CPU 使用率低。但這并不意味著物理核心負載低，因為兩個邏輯核心的負載都添加到了物理核心中。

這就導致負載較輕的情況下 SMT 系統與未采用 SMT 的系統相比，似乎有更多的剩余性能空間。但其實這可能是一個誤導。例如以下這個經過大幅簡化的場景：

兩個邏輯核心 LCore0 和 LCore1 在一個物理處理器上運行。

每個邏輯核心都運行一個處理 Web 請求的工作負載。每個請求需使用整個 CPU 0.1 秒進行處理，然后返回等待狀態。

在一秒的時間范圍內，LCore0 和 LCore1 分別為三個請求提供服務。

LCore0 的執行時間為 0.3 秒，空閑時間為 0.7 秒，因此計算得出 CPU 使用率為 30%。

LCore1 也是如此，同樣計算得出 CPU 使用率為 30%。

二者相加，物理處理器被充分使用的時間為 0.6 秒，因此實際使用率為 60%。

圖 1：SMT 下的 CPU 使用率說明

分析上述示例中的邏輯核心使用率時，使用者可能會推斷 CPU 的能力足以繼續處理 14 個 Web 請求。然而，實際 CPU 只能夠再處理四個請求。

需注意的是，與實際工作負載相比，上述示例經過簡化，實際工作負載的物理處理器使用率可能更低，具體取決于支持在邏輯核心之間共享物理處理器資源的動態條件。在嘗試預估系統上可能有多少可用性能空間時，這種不可預測性會是一項挑戰。

在本文中，我們將設計一個微型基準測試，以及使用實際工作負載在 SMT 系統上演示此行為。

微型基準測試

這個微型基準測試包含了大量讀數據和一些簡單數學運算。它會產生較大的 IPC，從而充分利用物理處理器的可用執行單元。為了模擬不同的負載水平，我們在計算循環中添加了不同的休眠時間。一級負載最輕，七級負載最重。在支持 SMT 的系統上，我們先在一個邏輯核心上運行程序，然后在同一物理處理器的兩個邏輯核心上同時運行程序。對從輕到重的所有負載水平都做同樣的測試。對于非 SMT 系統，我們使用 Neoverse N2 進行測試。對于雙核測試情形，我們使用連接到同一 Arm CMN 交叉點的兩個核。需注意的是，我們在編譯時禁用了向量化，因為實際工作負載中的大多數代碼不像該微型基準測試那樣容易實現向量化。

運行測試

我們在運行頻率為 3.5GHz 的主流 SMT 系統和未采用 SMT 的基于 Neoverse N2 的平臺 (2.7GHz) 上運行微型基準測試。

SMT

在我們的系統中，邏輯核心 0 和邏輯核心 32 共享同一個物理核心。因此，我們將在核心 0 和核心 32 上運行。

此處列舉了在兩個核心上同時運行微型基準測試的輸出示例。1000000000 是我們使用微型基準測試進行的計算輪數。7 是我們希望達到的負載級別。我們將使用 perf 工具來收集 time elapsed（即總運行時間）和 insn per cycle（即 IPC）。CPU 使用率通過 top 命令獲取。

收集到的結果如下所示：

從數據中可以看出，從三級和四級負載開始，LCore 0 和 LCore 1 的綜合 CPU 使用率逐漸超過 100%，相應地，兩個核心的 IPC 大幅下降。

非 SMT

在 Neoverse N2 平臺上，每個核心都是獨立的物理核心。我們將在核心 0 和核心 1 上運行。

結果表明，在 Neoverse 系統上，兩個核心的 IPC 與一個核心的 IPC 沒有太大的差別。而且，從輕負載到重負載，IPC 沒有下降。這一點與 SMT 系統截然不同。這意味著無論 CPU 使用率如何，CPU 的能力始終保持一致。

對結果的進一步分析

兩個硬件線程影響

要想找到一個可靠的直接指標來判斷物理核心的繁忙程度，這并非易事，但我們可以從其他角度進行判斷。在這里，我們選擇 IPC 進行分析。我們使用兩個核心運行得到的數據除以一個核心運行得到的數據。這可以揭示 SMT 系統的特點。

在下圖中，我們看到在輕負載的情況下，對于 SMT 系統，兩個核心和一個核心的 IPC 幾乎相同。這是因為物理核心并不繁忙，邏輯核心的所有操作幾乎都是以物理核心的最快速度運行，因此 IPC 非常高。CPU 使用率看起來很低。但物理核心實際運行的負載是一個邏輯核的兩倍。因此，物理 CPU 的使用率應該增加一倍。隨著負載的增加，與一個核心相比，兩個核心的 IPC 大幅降低。這是因為它們需要爭用和共享執行單元中的資源。此時物理核心已經滿載，無法像輕負載情況下那樣及時處理來自兩個核心的所有請求。最后，IPC 降至幾乎一半。這證明兩個邏輯核心正在共享物理核心。

相比之下，Neoverse 系統始終保持在 1，因為兩個核心是獨立的，無論負載水平如何，它們始終以相同的速度運行。

圖 2：微型基準測試 IPC 比較

性能與 CPU 使用率的對比

在這里，我們將性能定義為“1000000000/總運行時間”。1000000000 是我們使用微型基準工具進行的測試輪數。由于我們使用的 Neoverse N2 平臺的頻率 (2.7Ghz) 遠低于 SMT 系統 (3.5Ghz)，因此我們將 Neoverse N2 平臺的性能數據按比例調整為相同的 3.5Ghz。我們針對兩個核心的情況進行對比，因為在生產環境中，同時使用物理核心的兩個邏輯核心是最通常的用例。

下圖展示了頻率調整后的性能與 CPU 使用率?？梢钥吹剑S著 CPU 使用率的增加，SMT 系統的性能輸出變得平緩。與此同時，Arm 的性能輸出保持理想的線性增長趨勢，并最終在高 CPU 使用率區域性能超過了 SMT 系統。因此，如果僅使用低 CPU 使用率區域的性能輸出來預測 SMT 系統在高 CPU 使用率場景下的性能，可能會得到錯誤的結果。

圖 3：微型基準測試調整后的性能

在這里，我們又創建了“性能達成率”指標，即“性能/CPU 使用率”。性能數據來自上表。處理工作負載時，理想的系統應保持恒定的比率，即特定的 CPU 使用率應提供特定的性能輸出。

從該圖中可以看出，隨著 CPU 使用率的增加，SMT 系統的性能達成率大幅下降。而在 Arm 平臺上，性能達成率表現得更好且恒定。

圖 4：微型基準測試調整后的性能達成率

實際工作負載

下面試著用大家熟悉的工作負載來描述這個問題。在這里，我使用了 Flink 以及用于對 Flink 進行基準測試的 Nexmark。

測試說明

針對 SMT 系統和未采用 SMT 的基于 Neoverse N2 的系統，我們創建了兩個具有類似硬件資源的集群。軟件版本和配置也相同。

Nexmark 有多個測試用例，這里我們選擇 Q0 測試進行比較。其他的測試也會有類似輸出。

測試結果

Nexmark Q0 測試結果如下所示。對于 SMT 系統和 Arm 平臺，在相同負載水平 (TPS) 下，從 top 工具中得到的 CPU 使用率不同。

可以看到，當工作負載水平較低時，Arm CPU 使用率高于 SMT 系統，但當 CPU 使用率達到大約 50% 后，SMT 系統的 CPU 使用率增長得更快。最后，我們看到在高 CPU 負載下，SMT 系統 CPU 使用率遠高于 Arm 平臺。當 CPU 得到充分使用時，Arm 平臺可輸出更高的 TPS。

圖 5：不同 TPS 下的 Flink CPU 使用率

我們也可以從另一個角度來看：在相同的 CPU 使用率水平下，系統能夠生成的 TPS 數量的趨勢。起先，Arm 平臺表現得并不突出，但當 CPU 使用率達到大約 50% 后，Arm 的性能大幅提高。

圖 6：不同 CPU 使用率下的 Flink TPS

在這里，我們也創建了“性能達成率”指標，即 TPS/CPU_Usage。處理工作負載時，理想的系統應保持恒定的比率。從該圖中可以看出，隨著 CPU 使用率的增加，SMT 系統的性能達成率大幅下降。而在 Arm 平臺上，性能達成率表現得更好。

圖 7：Flink 性能達成率

因此，該 Flink 測試用例展示的結果與我們在微型基準測試中看到的結果相似。在輕負載場景下，Arm 平臺可能會顯示較高的 CPU 使用率。然而，超過某個點后，SMT 系統的 CPU 使用率會迅速超過 Arm，因此在高 CPU 使用率的情況下，SMT 系統的性能輸出下降。

結論

在輕負載場景下，支持 SMT 的系統的 CPU 使用率可能會被低估。在預估還有多少額外性能空間可供我們在機器上部署工作負載時，CPU 使用率指標可能具有誤導性。因此，在部署工作負載時，我們應在 CPU 被 100% 使用的情況下測試性能輸出水平，然后根據得到的值留出性能緩沖區，而不是簡單的根據 CPU 使用率預留性能空間。