PERF EVENT 硬體篇續 -- core/offcore/uncore

簡介

在上篇中，我們簡單介紹 PERF EVENT 如何在硬體層面給予測量性能的能力，在這篇中我們繼續針對硬體性能事件的類型做進一步介紹以理清我們日常在溝通中會遇到的一些概念。

在上篇介紹中我們介紹了三種事件捕捉實作

• 通用事件 PMCx & PERFEVETSELx
• 專用事件 FIXED_CTRx & FIXED_CTR_CTRL
• RDT

本片主要針對通用事件進行進一步描述

概念

cpu 内部元件是分層次構成的，是以性能事件根據此來進行劃分成 core/offcore/uncore 事件

core

core 即是在系統中檢視 /proc/cpuinfo 看到的最小核（邏輯核）

core 事件是最好了解的，即是跟邏輯核完全綁定的事件，如該核運作的 cycle 和 instruction 次數

offcore

在 cpu 硬體實作上又分邏輯核和實體核，邏輯核即是實體核上進行超線程技術虛拟出來的兩個核，實際上他們有一部分資源是共享的，而這部分資源被劃分到 offcore

offcore 事件稍微抽象點，它是由兩個（或者多個兄弟邏輯核）共享的一些事件，比如通路記憶體，因為在硬體上它們走的是同一個通道。本質上，它是一個 core 事件，但需要額外配置。

uncore

在實體核的層面上又有一部分資源是實體核共享的（同時也就是 cpu socket 的概念），比如 LLC 是一個 socket 共享，這部分資源被劃分為 uncore。

uncore 較為複雜，它不在是以 core 為視角采集性能事件，而是通過在共享資源如 LLC 的視角對接每個 core 裝置時提供各式各樣的 Box。再拿 LLC 舉例子，LLC 提供若幹 CBox 為每個 core 提供服務。是以 uncore 事件要建立在 CBox 元件上。如下圖所示

從圖中，我們可以看出 CBox 作為獨立于 Core 存在的元件，是可以被所有 core 可以通路到的，基于 uncore 事件的采集是以而被全局共享。這也造成了對 uncore 事件采集的複雜度（需要單獨指定 CBox）。

offcore性能事件采集

了解概念後，我們如何去采集 offcore 事件呢？Intel 是否為 offcore 準備單獨的計數寄存器和事件配置寄存器來處理 offcore 事件？

實際上，offcore 事件仍然複用通用事件寄存器 PMCx & PERFEVETSELx，但會有一些限制（文章後會提及）。在這個基礎上 Intel 在 offcore 上增加了幾個（一般是兩個，各個架構不同，位址也不同）名為 MSR_OFFCORE_RSPx 的寄存器，它被用來配置你需要采集的 offcore 事件。而在原有的通用事件寄存器中 PERFEVETSELx 永遠配置的是相同的 event 和 umask（這兩者原本用來指向 core 事件，現在被用來指向 MSR_OFFCORE_RSPx ），因為 MSR_OFFCORE_RSPx 已經幫你定義了你需要采集的事件類型。可能這樣說有點不直覺，我們來對比下流程

core 事件通用事件寄存器配置流程

1. 選取空閑事件寄存器id （0-3任意），選擇0
2. 配置對應的 PERFEVETSEL0，選擇 core 事件 L2_RQSTS.ALL_PF，查表找到對應事件的配置，将 event 字段配置成 0x24 umask 字段配置成 0xF8
3. 此時 PMC0 已經開始記錄 L2_RQSTS.ALL_PF 事件的次數

offcore 事件通用事件寄存器配置流程

2. 選擇空閑 MSR_OFFCORE_RSPx 來配置 offcore 事件 （0-1），選擇0，其對應的 event 為 0xB7 umask 為 0x01，msr offset 為 0x1a6 （以上資訊均查 Intel 手冊得到）
3. 配置對應的 PERFEVETSEL0，将 event 字段配置成 0xB7 umask 0x01
4. 将 2 步選擇的 MSR_OFFCORE_RSP0 進行配置 （之前隻是選擇後，配置到 PERFEVETSEL0，并未寫入offcore 事件選擇 ），配置 OFFCORE_RESPONSE.DEMAND_DATA_RD.L3_MISS.ANY_RESPONSE 事件，查表後得到需要将 0x3fffc00001 寫入位址為 0x1a6 的 msr
5. 此時 PMC0 已經開始記錄 OFFCORE_RESPONSE.DEMAND_DATA_RD.L3_MISS.ANY_RESPONSE 事件的次數

翻譯成 perf 指令行

perf stat -e cpu/event=0xB7,umask=0x01,offcore_rsp=0x3fffc00001/ /bin/ls           

發現該指令行與描述上存在的問題沒？

它并沒有指定 MSR_OFFCORE_RSP0 的 msr 位址， 經過筆者測試 event & umask 作為選擇子 linux 核心會發現 MSR_OFFCORE_RSP 對應 msr 位址，并且很神奇地複用有限的 MSR_OFFCORE_RSPx（上述指令指定 event=0xBB 效果完全一緻）。

offcore 與 core 使用上的差異

offcore 因為需要額外的配置寄存器，一般的 cpu 型号上隻有兩個，是以在一個實體核上一旦采集超過2個不同的事件，就會發生分時複用。

uncore性能事件采集

uncore 事件采集的硬體實作與通用實作類似，都是通過一對對事件選擇寄存器和事件計數寄存器來實作的。具體細節可檢視 Intel 手冊，這裡不再贅述。

在核心接口上，uncore 性能事件已經不是原本 core 上的 pmu 裝置了，是以原有的 perf 接口并不知道使用者采集哪個 CBox 上的性能資料，是以 perf_event 在原有的基礎上在 type 參數上進行擴充接口（換句話說 uncore 事件都是需要單獨的核心驅動的）。

好在核心在 /sys/devices/uncore_*/type 檔案直接暴露了該參數，在接口和工具的使用過程中，可以直接讀取該檔案的值，其餘使用方法與 core 事件一緻，下面是一個例子

perf stat -e "uncore_imc_1/cas_count_read/"  -a ls           

翻譯成 perf_event_open 參數就是

type=15,event=0x04,umask=0x03           

另外，因為 uncore 的獨立性也就是所謂 per-socket 事件，采集 uncore 事件要避免相同資料重複采集

總結

本篇補全了 cpu 硬體性能事件捕捉機制的在各個層次上的事件類型，實際上本文描述的事件類型外，随着 cpu 架構的發展，Intel 又引入了 RDT 事件類型，雖然他們在軟體層面都實作了 perf_event 的接口，但是在硬體層面上截然不同，從硬體實作上去了解各個事件的實作機制可以有效的了解和使用 perf 系統，以掌控系統性能的采集能力。阿裡雲系統組在性能采集的工作中開發了相關工具，其有效利用核心軟體和硬體性能采集機制來為各個業務方提供系統性能資料，同時，降低使用者使用 perf 子系統的門檻。

其他

PERF_EVENT 系列文章

1. PERF EVENT API篇
2. PERF EVENT 硬體篇
3. PERF EVENT 核心篇
4. PERF EVENT 硬體篇續