摘要

近期比較火的 CXL（Compute Express Link）因為其出色的異構硬件管理和內存一致性保證，非常適用于內存解聚（Memory Disaggregation）場景。但是目前還沒有實際落地的產品或者平臺將 CXL 整合到內存解聚中，為此這篇文章的團隊設計實現了 DIRECTCXL，它基于 CXL 的內存協議（CXL.mem）直接連接主機處理器群和遠程內存資源，并探索了 DIRECTCXL 在內存解聚場景中的性能。

目前對于 CXL 的實現比較稀少，該文既設計完成了 CXL 所需的硬件實現，并提供了 CXL 軟件運行時，允許用戶通過純粹的 load / store 指令來利用底層解聚的內存資源，還進行了不少測試，能在一定程度上反映 CXL 的性能。

背景

因為目前的內存解聚相關的研究大多數都是基于 RDMA 的，所以該文主要就是與 RDMA 對比。

設計與實現

Connecting Host and Memory over CXL

CXL devices and controllers

目前所有的 DRAM 模塊及其接口都被設計成無源外圍設備（passive peripherals），需要控制計算資源。且 CXL.mem 協議允許主機計算資源通過 PCIe 總線（FlexBus）直接訪問底層內存，其工作原理類似于本地 DRAM 與系統(tǒng)總線相連。所以該文將 CXL 設備設計和實現為純無源模塊（pure passive modules），并且每個模塊能夠擁有許多帶有自己硬件控制器的 DRAM DIMMs。該文的 CXL 設備應用了多個 DRAM 控制器，通過傳統(tǒng)的 DDR 接口連接 DRAM DIMMs。其 CXL 控制器然后通過許多 PCIe 通道將內部 DRAM 模塊暴露給 FlexBus。設備的 CXL 控制器解析進入的基于 PCIe 的 CXL 數據包（即 CXL flits 包），并將 CXL 數據包的信息（地址和長度）轉換為 DRAM 請求，并使用 DRAM 控制器從底層 DRAM 中提供響應這些請求。（基本翻譯，太硬件了，這里算是整體的介紹吧，下面是具體的細節(jié)設計）

Integrating devices into system memory

下圖展示了 CXL 設備如何通過 CXL 映射將內部 DRAM 暴露到主機的內存空間。主機 CPU 的系統(tǒng)總線包含一個或多個 CXL 根端口（root ports ，RPs），RPs 將一個或多個 CXL 設備作為端點（endpoint，EP）設備連接起來。主機端內核驅動程序首先通過 PCIe 事務（PCIe transactions）查詢 CXL 設備的基址寄存器（base address register，BAR）和其內部存儲器（其被稱為 host-managed device memory，HDM）的大小來枚舉 CXL 設備。內核驅動程序再根據檢索到的大小將 BAR 和 HDM 映射到主機的保留系統(tǒng)內存空間中，并讓 CXL 設備知道它們的 BAR 和 HDM 在主機系統(tǒng)內存中的映射位置。（這幾步對應圖中的綠色箭頭）當主機 CPU 通過 load / store 指令訪問 HDM 系統(tǒng)內存時，請求被傳遞到相應的 RP，RP 將請求轉換為 CXL flit，并傳送到 CXL 設備。 之后 CXL 設備中的 CXL 控制器解析 CXL flit，轉換傳入地址，并將轉換后的請求發(fā)送給底層 DRAM 控制器。 之后運行結果通過 CXL 交換機（CXL switch）和 FlexBus 返回給主機。（這幾步對應圖中的藍色箭頭）由于 HDM 訪問沒有軟件干預或內存數據副本，因此 DIRECTCXL 可以以低訪問延遲將 CXL 設備的內存資源暴露給主機。

Designing CXL network switch

下圖中的 a 展示了一個 host 如何使用 DIRECTCXL 將一個或多個 CXL 設備用于內存資源解聚，b 展示了 CXL 交換機的組織結構。主機的 CXL RP 直接連接到 CXL 交換機或 CXL 設備的上游端口 (upstream port ，USP)。 CXL 交換機的下游端口 (downstream port，DSP) 連接另一個 CXL 交換機的 USP 或 CXL 設備。 ?CXL 交換機有多個 USP 和 DSP。通過設置內部路由表， CXL 交換機的 fabric 管理器 (fabric manager，FM) 重新配置交換機的交叉開關以將每個 USP 連接到不同的 DSP，從而創(chuàng)建從根（主機）到終端（CXL 設備）的虛擬層次結構。 由于 CXL 設備可以使用一個或多個控制器和多個 DRAM，它還可以定義多個邏輯設備，每個邏輯設備都將自己的 HDM 暴露給主機。 每個 CXL 虛擬層次結構僅提供從一個到另一個的路徑，以確保沒有主機共享一個 HDM。（大致就是主機能直接連接 CXL 設備，或者通過 CXL 交換機連接 CXL 設備）

Software Runtime for DirectCXL

一旦主機和 CXL 設備之間建立了虛擬層次結構，運行在主機上的應用程序可以通過引用 HDM 的內存空間直接訪問 CXL 設備。為了實現這點，需要軟件運行時 / 驅動程序（runtime / driver）來管理底層 CXL 設備并將其 HDM 暴露在應用程序的內存空間中。然后該文實現了 DIRECTCXL 運行時，它簡單地將 HDM 的地址空間分成多個稱為 CXL 命名空間（ cxl-namespace） 的段。 然后，DIRECTCXL 運行時允許應用程序將每個 CXL 命名空間作為內存映射文件 (mmap) 進行訪問。

下圖演示了應用程序如何通過 DIRECTCXL 運行時使用 CXL 設備的內存。當檢測到 CXL 設備時（在 PCIe 枚舉時），DIRECTCXL 驅動程序會創(chuàng)建一個入口設備（例如 /dev/directcxl）以允許用戶通過 ioctl 管理 CXL 命名空間。如果用戶向 /dev/directcxl 請求 CXL 命名空間，驅動程序通過引用其 HDM 段表來檢查 HDM 上的物理連續(xù)地址空間，其條目包括段的偏移量、大小和引用計數（記錄有多少 CXL 命名空間指向此段）。 因為此表可以被多個進程訪問，所以其表頭還保留必要的信息，例如自旋鎖、讀 / 寫鎖和表條目的摘要（例如，有效條目號）。 一旦 DIRECTCXL 驅動程序根據用戶請求分配了一個段，它就會為 mmap 創(chuàng)建一個設備（例如 /dev/cxl-ns0）并更新段表。 然后，用戶應用程序可以使用帶有 vm_area_struct 的 mmap 將 CXL 命名空間映射到其進程虛擬內存空間。（這段大致就是實際通過 DIRECTCXL 調用 CXL 設備上內存的底層軟件邏輯）

CXL 命名空間類似于常規(guī)的內存段，它直接暴露給應用程序而無需使用文件系統(tǒng)。

Prototype Implementation

下圖 a 是該文設計的用于內存解聚的 CXL 網絡拓撲，圖 b 是實際物理實現圖。N 個主機可以通過 CXL 交換機連接 M 個 CXL 設備。實際的實現為 4 和主機和 4 個 CXL 設備，理論上可以拓展。每個 CXL 設備原型都是由采用 16 納米 FPGA 和 8 個不同的 DDR4 DRAM 模塊（64GB）的定制 AIC CXL 內存片（add-in-card CXL memory blade）構建。并在 FPGA 中制造了 1 個 CXL 控制器和 8 個 DRAM 控制器，每個控制器管理 CXL 端點和內部 DRAM 通道。 因為當時還沒有支持 CXL 的處理器架構，所以該團隊還使用 RISC-V ISA 構建了自己的內部主機處理器，該處理器采用了 4 個亂序內核（out-of-order cores），其末級緩存 (last-level cache，LLC) 實現了 CXL RP。每個支持 CXL 的主機處理器充當主機，可以單獨運行 Linux 5.13 和 DIRECTCXL 軟件運行時，并通過 PCIe 背板將 4 個 CXL 設備（32 個 DRAM 模塊）暴露給 4 個主機。還用另一個實現 DIRECTCXL 的 CXL 交換機的加速卡擴展了背板。該交換機實現了 FM，可以創(chuàng)建多個虛擬層次結構，每個虛擬層次結構以靈活的方式連接主機和 CXL 設備。（看著就是基本從零實現了整套之前設計的 CXL 框架的物理實現）

主機端處理器需要高級配置和電源接口 (advanced configuration and power interface ，ACPI ) 來進行 CXL 2.0 枚舉（例如，RP 位置和 RP 的保留地址空間），但是 RISC-V 尚不支持 ACPI，所以該文團隊通過將此類信息添加到設備樹中來啟用 CXL 枚舉，具體就是通過更新指定為樹節(jié)點屬性的 MMIO 寄存器，讓處理器知道 CXL RP 存在的位置。 另一方面，在節(jié)點中添加一個新字段（cxl-reserved-area）以指示可以映射 HDM 的位置。 內部軟核處理器以 100MHz 的速度運行，CXL 和 PCIe IP（RP、EP 和 Switch）以 250MHz 的速度運行。

實驗

Testbed prototypes for memory disaggregation

CXL 相關的上面實現部分介紹了。對比對象 RDMA 用 Mellanox ConnectX-3 VPI InfiniBand RNIC（56Gbps），Mellanox OpenFabric Enterprise Distribution (OFED) v4.9。

實驗中的 local 是將主機處理器配置為僅使用其本地 DRAM。

In-depth Analysis of RDMA and CXL

比較的是 RDMA 和 CXL 的性能差距，都是一對一的連接，讀取 64 字節(jié)的時延分析結果如下圖。根據 ATC 上的演講視頻，首先下面的時延僅僅包括 遠端數據發(fā)送到本地 這一操作，不是一次完整的 RTT。接著具體看實驗結果圖，其中 RDMA 時延中第一個 DMA 時延是遠端主機將數據放到 RNIC 上的時延，包括1. 找要讀取的數據位置等操作的時延（灰黑色 Memory 部分）和具體數據通過 PCIe 傳輸到網卡的時延（白色 PCIe 部分）；之后是數據通過網絡傳輸的時延（斜線 Network 部分）；最后是將數據從網卡內存用 DMA 傳到本地主機的時延。DirectCXL 的時延根據視頻，先是要本地主機發(fā)現 cache miss （紅色的 CPU cache 部分），然后是 CXL 設備上的控制器 load 設備上的內存（灰黑色 Memory 部分），最后控制器直接通過 PCIe 總線將數據發(fā)送給主機（白色 PCIe 部分o）。

然后文章說法 RDMA 需要兩次 DMA 操作，InfiniBand 網絡的通信開銷占總延遲（2705 個周期）的 78.7%（2129 個周期）。相比之下，DirectCXL 的內存加載請求只需要 328 個周期，比 RDMA 快 8.3 倍?？斓脑颍?. DirectCXL 使用 PCIe 直接連接計算節(jié)點和內存節(jié)點，相比 RDMA 少了 InfiniBand 和 PCIe 之間協議/接口的轉換； 2. DirectCXL 可以將來自 LLC 的內存 load/store 請求轉換為 CXL flits，而 RDMA 必須使用 DMA 從/向內存讀取/寫入數據。

目前比較疑惑的是，按照之前的設計 CXL flits 數據包到 CXL 設備是不是也需要額外的時延，使用一次完整的 RTT 時延是不是更有實際的意義一點，雖然單次的數據傳輸也能反映較多的問題（RDMA 操作也有會控制信息數據包的傳遞）。如果物理鏈路是相同的話，側面反映協議的轉換協議的開銷是真的大，因為這里 RDMA 中的網絡傳輸可以對應 CXL 中的 PCIe 傳輸。

Sensitivity tests

下圖 a 將 RDMA 延遲分解為基本硬件（Memory 和 Network）、軟件（Library）和數據傳輸（Copy）的延遲。隨著有效負載的增加，Copy 時延變長，達到總執(zhí)行時間的 28.9%， 這是因為用戶必須將所有的數據復制到 RNIC 的 MR 中，這在 RDMA 中會產生額外的開銷。 Network 的實際時延不會隨著有效負載的增加而減少； 當 Memory 增加處理大量數據時，RNIC 可以同時將數據傳輸到底層網絡，圖中這些重疊的周期并入了 Memory 中。

圖 b 是 DirectCXL 時延的分解。因為 CXL 運行時處理完了底層的 CXL 內存調度，就沒有了軟件時延（個人理解 ）。隨著有效負載的增加，DirectCXL 延遲的主要組成部分是 LLC（CPU Cache），因為 LLC 可以通過自定義 CPU 中的未命中狀態(tài)保持寄存器（miss status holding registers，MSHR）處理 16 個并發(fā)未命中，構成大量有效載荷數據的許多內存請求 (64B) 可能會在 CPU 處停滯，這占用了總延遲的 67% 來處理 4KB 有效載荷（純翻譯。。）。 由于 RDMA 網絡有類似情況，圖 a 中所示的 PCIe 不會隨著有效載荷的增加而減少。圖中顯示的 PCIe 時延包括 CXL IP（RP、EP 和 Switch）的延遲，不是 PCIe 物理總線的純周期時延。 PCIe 物理總線 (FlexBus) 的純周期占 DirectCXL 延遲的 28%。

Memory hierarchy performance

下圖看看就行。感覺 DirectCXL 使用 size 小的時候就直接假設數據在主機的 Cache 里面了，所以和 Local 時延一樣，甚至最小只要 4 個周期。

Latency Distribution and Scaling Study

和上一個差不多， 感覺 DirectCXL 使用 size 小的時候就直接假設數據在主機的 Cache 里面了，不放了。

大致說，硬件提升了，性能會更好。

Performance of Real Workloads

圖中所有結果都標準化為 Swap 的結果。圖 a 顯示沒有源碼修改的 DirectCXL 的性能分別比 Swap 和 KVS 高出 3 倍和 2.2 倍。

圖 b 對應用的具體時延進行了分解。

個人看法

個人認為這篇文章最大的貢獻是設計實現了 CXL 2.0 的 mem 協議，并給出了實驗數據，讓 CXL 不在那么空洞，有了現實支撐。CXL 的概念最近是炒的很火熱，但是目前市場上還是沒有太多通用的硬件設備和相關的配套軟件，有些許空洞。希望 CXL 盡快有通用的商用產品。

如果問題，歡迎批評指正~