ATC22

近期比较火的 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 与系统总线相连。所以该文将 CXL 设备设计和实现为纯无源模块（pure passive modules），并且每个模块能够拥有许多带有自己硬件控制器的 DRAM DIMMs。该文的 CXL 设备应用了多个 DRAM 控制器，通过传统的 DDR 接口连接 DRAM DIMMs。其 CXL 控制器然后通过许多 PCIe 通道将内部 DRAM 模块暴露给 FlexBus。设备的 CXL 控制器解析进入的基于 PCIe 的 CXL 数据包（即 CXL flits 包），并将 CXL 数据包的信息（地址和长度）转换为 DRAM 请求，并使用 DRAM 控制器从底层 DRAM 中提供响应这些请求。（基本翻译，太硬件了，这里算是整体的介绍吧，下面是具体的细节设计）

Integrating devices into system memory

下图展示了 CXL 设备如何通过 CXL 映射将内部 DRAM 暴露到主机的内存空间。主机 CPU 的系统总线包含一个或多个 CXL 根端口（root ports ，RPs），RPs 将一个或多个 CXL 设备作为端点（endpoint，EP）设备连接起来。主机端内核驱动程序首先通过 PCIe 事务（PCIe transactions）查询 CXL 设备的基址寄存器（base address register，BAR）和其内部存储器（其被称为 host-managed device memory，HDM）的大小来枚举 CXL 设备。内核驱动程序再根据检索到的大小将 BAR 和 HDM 映射到主机的保留系统内存空间中，并让 CXL 设备知道它们的 BAR 和 HDM 在主机系统内存中的映射位置。（这几步对应图中的绿色箭头）当主机 CPU 通过 load / store 指令访问 HDM 系统内存时，请求被传递到相应的 RP，RP 将请求转换为 CXL flit，并传送到 CXL 设备。 之后 CXL 设备中的 CXL 控制器解析 CXL flit，转换传入地址，并将转换后的请求发送给底层 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，从而创建从根（主机）到终端（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 驱动程序会创建一个入口设备（例如 /dev/directcxl）以允许用户通过 ioctl 管理 CXL 命名空间。如果用户向 /dev/directcxl 请求 CXL 命名空间，驱动程序通过引用其 HDM 段表来检查 HDM 上的物理连续地址空间，其条目包括段的偏移量、大小和引用计数（记录有多少 CXL 命名空间指向此段）。 因为此表可以被多个进程访问，所以其表头还保留必要的信息，例如自旋锁、读 / 写锁和表条目的摘要（例如，有效条目号）。 一旦 DIRECTCXL 驱动程序根据用户请求分配了一个段，它就会为 mmap 创建一个设备（例如 /dev/cxl-ns0）并更新段表。 然后，用户应用程序可以使用带有 vm_area_struct 的 mmap 将 CXL 命名空间映射到其进程虚拟内存空间。（这段大致就是实际通过 DIRECTCXL 调用 CXL 设备上内存的底层软件逻辑）

CXL 命名空间类似于常规的内存段，它直接暴露给应用程序而无需使用文件系统。

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，可以创建多个虚拟层次结构，每个虚拟层次结构以灵活的方式连接主机和 CXL 设备。（看着就是基本从零实现了整套之前设计的 CXL 框架的物理实现）

主机端处理器需要高级配置和电源接口 (advanced configuration and power interface ，ACPI ) 来进行 CXL 2.0 枚举（例如，RP 位置和 RP 的保留地址空间），但是 RISC-V 尚不支持 ACPI，所以该文团队通过将此类信息添加到设备树中来启用 CXL 枚举，具体就是通过更新指定为树节点属性的 MMIO 寄存器，让处理器知道 CXL RP 存在的位置。 另一方面，在节点中添加一个新字段（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 字节的时延分析结果如下图。根据 ATC 上的演讲视频，首先下面的时延仅仅包括 远端数据发送到本地 这一操作，不是一次完整的 RTT。接着具体看实验结果图，其中 RDMA 时延中第一个 DMA 时延是远端主机将数据放到 RNIC 上的时延，包括1. 找要读取的数据位置等操作的时延（灰黑色 Memory 部分）和具体数据通过 PCIe 传输到网卡的时延（白色 PCIe 部分）；之后是数据通过网络传输的时延（斜线 Network 部分）；最后是将数据从网卡内存用 DMA 传到本地主机的时延。DirectCXL 的时延根据视频，先是要本地主机发现 cache miss （红色的 CPU cache 部分），然后是 CXL 设备上的控制器 load 设备上的内存（灰黑色 Memory 部分），最后控制器直接通过 PCIe 总线将数据发送给主机（白色 PCIe 部分o）。

然后文章说法 RDMA 需要两次 DMA 操作，InfiniBand 网络的通信开销占总延迟（2705 个周期）的 78.7%（2129 个周期）。相比之下，DirectCXL 的内存加载请求只需要 328 个周期，比 RDMA 快 8.3 倍。快的原因：1. DirectCXL 使用 PCIe 直接连接计算节点和内存节点，相比 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 时延变长，达到总执行时间的 28.9%， 这是因为用户必须将所有的数据复制到 RNIC 的 MR 中，这在 RDMA 中会产生额外的开销。 Network 的实际时延不会随着有效负载的增加而减少； 当 Memory 增加处理大量数据时，RNIC 可以同时将数据传输到底层网络，图中这些重叠的周期并入了 Memory 中。

图 b 是 DirectCXL 时延的分解。因为 CXL 运行时处理完了底层的 CXL 内存调度，就没有了软件时延（个人理解 ）。随着有效负载的增加，DirectCXL 延迟的主要组成部分是 LLC（CPU Cache），因为 LLC 可以通过自定义 CPU 中的未命中状态保持寄存器（miss status holding registers，MSHR）处理 16 个并发未命中，构成大量有效载荷数据的许多内存请求 (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 尽快有通用的商用产品。

如果问题，欢迎批评指正~