揭开CXL内存的神秘面纱

在数据中心存储和处理数据的爆炸性需求、以及传统DDR内存接口的有限带宽和容量可扩展性，要求采用新的内存接口技术和系统架构。其中，Compute eXpress Link（CXL）已成为业界和学术界最有前途的技术之一，不仅用于内存容量/带宽扩展，还用于内存分解。

CXL是由主要硬件供应商和云提供商于2019年共同制定的开放标准，目前仍在快速发展。具体来说，与传统的PCIe互连相比，它提供了一组新功能，使CPU能够以具有加载/存储语义的高速缓存一致方式与外围设备（及其连接的存储器）通信。因此，与内存相关的设备扩展是CXL的主要目标场景之一。

作为未来数据中心的事实标准，主要硬件供应商已在其产品路线图中宣布支持CXL。鉴于CXL存储器的受欢迎程度和前景，它备受关注。然而，由于缺乏支持CXL的商用硬件（尤其是CPU），最近对CXL内存的研究都是基于使用多插槽NUMA系统的仿真，因为CXL内存被公开为NUMA节点。因此，这些研究可能无法准确地对现实世界中的CXL内存进行建模和表征。

随着Intel第4代Xeon可扩展CPU（Sapphire Rapids或SPR）和商用CXL设备的出现，我们能够开始了解CXL存储器的实际特性，并定制能够充分利用这些特性的软件系统。在这项工作中，我们在由Intel SPR CPU和基于Intel Agilex-I FPGA的CXL存储器（R-Tile中加固的CXL控制器）组成的测试台上，对具有多个微基准和端到端应用程序的CXL内存进行了全面分析。从我们的微基准标记中，我们发现CXL内存的行为与远程NUMA节点中的内存不同，后者通常用于仿真。与基于NUMA的内存相比，真正的CXL内存具有：（1）更高的延迟，（2）更少的内存通道（导致更低的吞吐量），以及（3）在各种操作下不同的传输效率。

基于上述观察，我们还将CXL内存应用于表现出不同内存访问行为的三个实际应用程序。我们发现它们对CXL内存卸载有不同的敏感性。具体而言，我们发现（1）μs延迟数据库对内存延迟的增加高度敏感，（2）当数据库在CXL内存上运行时，具有中间计算层的ms延迟微服务受到的影响较小，（3）内存密集型ML推理对CXL内存提供的随机访问吞吐量敏感。在所有情况下，在连接CPU的DRAM和CXL内存之间交错内存可以减少CXL内存带来的性能损失。

接下来，在分析了在使用CXL内存的系统上运行的微基准和应用程序的性能特征后，我们为用户提供了一些实用的指导方针，以优化他们的软件堆栈/库以获得最高性能。例如，应该使用在CXL内存和DRAM之间均匀分布的带宽来最大限度地提高性能；应当使用高速缓存旁路指令来进行从CXL存储器到CXL存储器的数据移动；对于单个CXL内存通道，由于几个线程很容易使负载或存储带宽饱和，因此应该限制对CXL内存的写线程数量，以减少写干扰；并且应该针对以毫秒级延迟运行的读取量大的应用程序，其中较高的CXL内存延迟可以通过中间计算来分摊。

本文的其余部分组织如下。我们在第2章中简要介绍了CXL，并在第3章中描述了我们的实验设置。然后，我们在第4章中用我们的微基准来分析CXL记忆，在第5章中用三个有代表性的应用来介绍我们的发现。最后，我们在第6章中提供了一些有效利用CXL内存的指南。

PCI Express（PCIe）是高速串行计算机扩展总线的标准，它取代了旧的PCI总线。自2003年以来，每一代的带宽都翻了一番，截至PCIe Gen 5，带宽已达到32 GT/s（即64 GB/s，带16个通道）。其点对点拓扑结构借助带宽的增长，实现了与PCIe连接设备（如图形处理单元（GPU）、网络接口卡（NIC）和NVMe固态硬盘（SSD））的低延迟、高带宽通信。

CXL在PCIe物理层上构建缓存一致性系统。与标准PCIe通信类似，在标准PCIe通信中，数据传输使用事务层数据包（TLP）报头和数据链路层数据包，CXL协议的子集使用预定义的报头和16B块来传输数据。在CXL 1.1中，根据协议和传输的数据，CXL硬件将根据CXL规范中描述的一组规则，将标头和数据打包到68 B flit（64 B CXL数据+2 B CRC+2 B协议ID）中。除非另有说明，否则在本文的剩余部分中，CXL指的是CXL 1.1。

CXL标准定义了三个独立的协议：CXL.io、CXL.cache和CXL.mem。CXL.io使用标准PCIe中的TLP和DLLP等功能，主要用于协议协商和主机设备初始化。CXL.cache和CXL.mem分别为设备访问主机的内存和主机访问设备的内存使用上述协议头。

通过将这三种协议相结合，CXL为不同的用例确定了三种类型的设备。Type-1设备使用CXL.io和CXL.cache，它们通常指的是不应用主机管理内存的SmartNIC和加速器。Type-2设备支持所有三种协议。这些设备，如GP GPU和FPGA，具有主机CPU可以访问和缓存的附加内存（DRAM、HBM），并且它们还使用CXL.cache进行设备到主机的内存访问。Type-3设备支持CXL.io和CXL.mem，并且这些设备通常被视为对现有系统的内存扩展。在本文中，我们将重点介绍Type-3设备，并介绍CXL.mem的较低级别细节。

由于CXL.mem协议只考虑主机到设备的内存访问，因此该协议由两个简单的内存访问组成：从主机到设备内存的读取和写入。每次访问都伴随着来自设备的完成回复。从设备内存读取时，应答包含数据，在写入时仅包含完成标头。图1显示了这些访问路线。

图1：支持CXL的典型系统体系结构（左）和内存事务流

CXL.mem协议在CPU归属代理和设备上的CXL控制器之间进行通信。当归属代理处理协议时，CPU以与访问DRAM相同的方式发出加载和存储指令来访问存储器。这比其他内存扩展解决方案（如远程直接内存访问（RDMA））具有优势，后者涉及设备上的DMA引擎，因此具有不同的语义。将加载/存储指令与CXL.mem集成还意味着CPU将在其所有级别的缓存中缓存PCIe连接的内存，这对于除持久内存之外的任何其他内存扩展解决方案来说都是不可能的。

CXL需要主机CPU端和设备端的支持。截至目前，除了一些研究原型外，三星、SK海力士、美光和澜起等主要硬件供应商还设计了多个支持CXL的存储设备。为了促进更灵活的内存功能和近内存计算研究，英特尔还在其最新的Agilex-I系列FPGA上启用CXL.mem，其中CXL和内存相关的IP核在小芯片上进行硬编码，以实现高性能。在主机CPU方面，Intel最新的第4代Xeon可扩展处理器（代号Sapphire Rapids，SPR）是第一款支持CXL1.1标准的高性能商用CPU。我们预计，在不久的将来，越来越多的硬件供应商的产品将支持更丰富的CXL。

在这项工作中，我们使用两个测试台来评估最新的商品CXL硬件，如表1所示。该服务器配备Intel Gold 6414U CPU和128 GB CXL.mem协议以及4800MT/s DDR5 DRAM（分布在8个内存通道中）。在第4代中，Intel Xeon CPU被实现为四个单独的小芯片。用户可以决定使用这4个小芯片作为统一处理器（即共享的末级缓存（LLC）、集成内存控制器（iMC）和根复合体），或者在子NUMA集群（SNC）模式下，每个小芯片作为一个小NUMA节点运行。这种灵活性允许用户微调系统以适应其工作负载特性，并对资源共享和隔离进行细粒度控制。在我们的实验中，我们将探索SNC和CXL.mem之间的内存交错将如何影响应用程序的性能。我们还在双插槽系统上进行了一些实验，该系统具有两个Intel Platinum 8460H和相同的DDR5 DRAM，以在基于NUMA的常规内存和CXL.mem之间进行一些比较。

表1：试验台配置

对于CXL内存设备，系统有一个Intel Agilex-I开发套件。它有16 GB 2666MT/s DDR4 DRAM作为CXL内存，并通过x16 PCIe Gen 5接口连接到CPU。它作为一个具有16GB内存而没有CPU内核的NUMA节点透明地暴露给CPU和OS，并且CXL内存的使用与常规的基于NUMA的内存管理相同。

请注意，CXL协议本身并没有定义底层内存的配置。这样的配置包括但不限于容量、介质（DRAM、持久存储器、闪存芯片等）和存储器通道的数量。因此，不同的器件可能表现出不同的性能特征。

在本节中，我们介绍了使用我们的微基准来评估CXL内存的发现。我们相信，这一分析深入解读了CXL内存用户如何根据他们的用例更有效地利用CXL内存。我们还将这些结果与最近关于CXL内存的一些工作中的假设和模拟进行比较，在这些工作中，CXL内存是使用具有一些额外延迟的跨NUMA数据访问来模拟的。

为了彻底检查CXL内存的能力，我们开发了一个称为MEMO的微基准测试。此基准测试旨在针对CXL内存的各种用例，并在Linux用户空间上运行。用户可以提供命令行参数来指定MEMO要执行的工作负载。之后我们计划开源MEMO。

特别地，MEMO具有以下能力：（1）通过使用NUMA_lalloc_node函数从不同的源分配内存，包括本地DDR5内存、CXL内存无CPU NUMA节点或远程DDR5，（2）启动指定数量的测试线程，将每个线程固定到一个内核，并可选地启用或禁用内核，以及（3）使用内联汇编语言执行存储器访问。基准测试报告不同指令（如加载、存储和非临时存储）的内存访问延迟或聚合带宽，所有内存访问都使用AVX-512指令完成。此外，MEMO可以在内存区域上执行指针跟踪，并且通过改变工作集大小（WSS），基准可以显示平均访问延迟如何随着WSS跨越缓存层次结构的不同大小而变化。

在延迟测试中，MEMO从刷新测试地址的缓存线开始，并立即发出mfence指令。然后，MEMO发出一组nop指令来刷新CPU管道。当使用加载指令进行测试时，我们记录访问清空的缓存行所花费的时间；当使用存储指令进行测试时，我们记录执行临时存储所需的时间，然后记录缓存线写回（clwb），或者记录非临时存储的执行时间，然后再记录sfence。此外，我们测试了在禁用所有预取的情况下，在大内存空间中通过指针追逐的平均访问延迟。图2显示了四条测试指令的延迟，1GB内存空间下的平均指针追逐延迟，以及不同工作集大小下的指针追逐延迟。

图2：访问延迟。1GB空间中单AVX512加载（ld）、存储和回写（st+wb）、非临时存储（nt-st）和顺序指针追逐（ptr-chase）的平均延迟；连续指针追踪延迟与工作集大小（右）。在这两种情况下，都会禁用所有级别的预取

我们的结果（图2）显示，CXL内存访问延迟比8通道本地DDR5（DDR5-L8）访问高约2.2倍，而单通道远程DDR5比DDR5-L8高约1.27倍。根据先前对持久存储器的研究，访问最近刷新的高速缓存线可能会比正常的高速缓存未命中访问产生更高的延迟，这是由于此类刷新高速缓存线的额外高速缓存一致性握手导致的。指针追逐反映了应用程序所经历的更现实的访问延迟。在MEMO中，工作集首先在预热运行中被引入缓存层次结构。图2中的右图显示了不同工作集大小下的平均内存访问时间。指针追逐延迟的每次跳跃对应于跨越L1、L2和LLC大小的边界。图2中的结果显示，CXL内存中的指针追逐延迟比DDR5-L8访问高4倍。CXL内存上的指针追逐延迟比DDR5-R1访问高2.2。有趣的是，当工作集大小在4MB到32MB之间时，与CXL内存相比，DDR5-R1表现出更高的延迟。我们认为这种差异可归因于LLC大小的差异，Xeon 8460H的LLC大小几乎是Xeon 6414U的两倍。

值得注意的是，尽管CXL控制器和DDR4存储器控制器在FPGA芯片上得到了加固，但CXL存储器较长的访问延迟可部分归因于其FPGA实现。尽管我们预计CXL存储器设备的ASIC实现将导致延迟的改善，但我们认为它仍将高于常规的跨NUMA访问，这主要是由于与CXL协议相关的开销。此外，我们在第5节中的实际应用程序评测显示，根据应用程序的特定特性，延迟惩罚有所减少。还应该注意的是，基于FPGA的CXL设备的好处在于它们能够在CXL存储器数据路径上添加（内联）加速逻辑，以及以接近存储器的方式卸载存储器密集型任务。

另一方面，CXL内存上具有sfence的非临时存储指令的延迟明显低于临时存储后的缓存线写回。这两种操作都将数据从CPU核心传输到CXL内存，而延迟差异约为2.6倍。这种延迟差异是由于CXL的MESI缓存一致性协议中的所有权读取（RFO）行为造成的，在该协议中，每次存储未命中都会将缓存线加载到缓存中。这种访问延迟的差异稍后会转化为带宽差异，这将在第4.3节中讨论。

在我们的带宽测试中，MEMO在每个测试线程中执行顺序或随机访问块。主程序通过对访问的字节数求和来计算固定间隔的平均带宽。为了便于公平比较内存通道数，我们测试了远程DDR5，在CXL内存旁边只有一个内存通道（DDR5-R1）。

4.3.1 顺序访问模式

顺序访问反映了内存方案在特定操作下的最大可能吞吐量，结果如图3所示。在使用DDR5-L8进行测试期间，我们观察到负载带宽线性缩放，直到其峰值达到221 GB/s的最大带宽，大约有26个线程。相比之下，非临时存储指令达到了170GB/s的最大带宽，这低于加载指令的带宽，但线程数较低，约为16。

图3：顺序访问带宽。实验显示了8通道（a）的本地DDR5、CXL内存（b）和1通道（c）的远程DDR5的最大可能带宽。（b）中的灰色虚线显示DDR4-2666MT/s的理论最大速度

相比之下，与DDR5-L8相比，CXL存储器表现出明显的带宽趋势。具体来说，通过加载指令，CXL内存可以在大约8个线程的情况下达到其最大带宽，但当线程数增加到12个线程以上时，这个值会降至16.8 GB/s。另一方面，非临时存储仅用2个线程就展示了令人印象深刻的22GB/s的最大带宽，这接近于测试DRAM的最大理论带宽。然而，当我们增加线程数时，这个带宽会立即下降，这表明FPGA内存控制器受到了一些干扰。

CXL内存的时间存储带宽显著低于非时间存储，这与图4.2中报告的时间存储的高延迟一致。这种差异是由于第4.2节中描述的时间存储中的RFO行为造成的，这显著降低了CXL存储器的传输效率。这种减少是因为与非临时存储相比，RFO需要额外的核心资源和额外的微片往返来加载和驱逐高速缓存行。

图4：数据传输带宽。显示不同工作负载下数据传输效率的实验。D2C是local-DDR5到CXL内存的缩写。（b）中的所有实验都是用单个线程完成的。

此外，图3c显示DDR5-R1的顺序访问性能与CXL内存类似。由于DDR5和UPI互连具有更高的传输速率和更低的延迟，DDR5-R1在负载和非临时存储中显示出更高的吞吐量，但在临时存储中表现出类似的吞吐量。

除了上述指令外，我们还测试了一条新的x86指令movdir64B，它是SPR上新提供的指令。该指令将64B数据从源内存地址移动到目标内存地址，并明确绕过缓存加载源并将其存储到目标位置。如图4a所示，我们的结果表明，D2*操作表现出类似的行为，而C2*操作通常表现出较低的吞吐量。从这些结果中，我们可以得出结论，来自CXL内存的较慢负载会导致movdir64B的吞吐量较低，在C2C的情况下更是如此。

作为SPR的新产品，Intel Data Streaming Accelerator（Intel DSA）使内存移动操作能够从主机处理器上卸载。Intel DSA由工作队列（WQ）和处理引擎（PE）组成，前者用于保存已卸载的工作描述符，后者用于从WQ中提取描述符以进行操作。描述符可以通过等待每个已卸载的描述符完成后再卸载另一个描述符来同步发送，也可以通过连续发送描述符来异步发送，从而使WQ有许多正在运行的描述符。通过设计程序以最佳方式异步使用Intel DSA，可以实现更高的吞吐量。为了进一步提高吞吐量，可以对操作进行批处理以摊销卸载延迟。图4b显示了通过memcpy（）或movdir64B在主机处理器上执行内存复制操作，并使用不同批处理大小（如1、16和128）的Intel DSA同步/异步执行内存复制时观察到的最大吞吐量。虽然到Intel DSA的非批处理同步卸载与非批处理内存复制的吞吐量相匹配，但任何级别的异步或批处理都会带来改进。此外，与仅使用CXL连接的内存相比，拆分源数据位置和目标数据位置可产生更高的吞吐量，C2D案例报告称，由于DRAM上的写入延迟较低，因此吞吐量更高。

在我们的带宽分析过程中，我们观察到了线程数量增加导致带宽减少的情况。虽然数据访问在每个工作线程内是顺序的，但随着线程数的增加，CXL控制器和扩展DRAM之间的内存控制器接收到的请求模式更少。因此，CXL内存的性能受到了阻碍。

4.3.2 随机存取模式

为了评估MEMO对随机块访问的性能，我们按顺序发布AVX-512访问的块，但每次都有随机偏移。这种方法使我们能够在数据访问模式不可预测的现实工作条件下测量系统的性能。随着我们在测试的线程计数中增加块大小，内存访问模式将收敛到顺序访问，其中CPU缓存和内存控制器都可以提高整体带宽。为了确保块级别的写入顺序，我们在nt存储的每个块之后发布一个sfence。随机块访问的结果如图5所示。

图5：随机块访问带宽。行顺序（从上到下）：本地DDR5、CXL内存、远程DDR5。列顺序（从左到右）：加载、存储、nt存储。线程数在顶部图例中表示

当块大小较小（1KB）时，我们在随机块加载中观察到类似的模式，所有三种存储器方案都同样受到随机访问的影响。然而，当我们将块大小增加到16KB时，DDR5-L8和DDR5-R1/CXL内存之间出现了主要差异。DDR5-L8的带宽随线程数呈次线性扩展，而DDR5-R1和CXL内存从更高的线程数（4个线程后）中获益较少，这在CXL内存中更为明显。内存通道数起着至关重要的作用，DDR5-R1和我们的CXL内存设备只有一个内存通道，而DDR5-L8总共有八个通道。随机块存储在线程数方面表现出与负载相似的模式，但增加了带宽停止随块大小缩放的趋势。

与所有其他测试的工作负载相比，CXL内存中随机块非临时存储的行为显示出一个有趣的趋势。单线程nt存储可以很好地随块大小扩展，而线程数越高，在达到块大小和线程数的一些最佳点后，吞吐量就会下降。例如，当块大小为32KB时，2线程带宽达到峰值，而4线程带宽在块大小为16KB时达到峰值。

我们认为，这个最佳点是由CXL内存设备内的内存缓冲区决定的。与常规存储指令不同，nt存储不占用CPU核心中的跟踪资源。因此，更容易同时拥有更多的动态nt存储指令，这可能会导致CXL内存设备中的缓冲区溢出。

尽管如此，非临时指令的优点是避免了RFO（第4.2节）和缓存污染，使它们在CXL内存设置中更具吸引力。希望使用nt存储的程序员应该记住这种行为，以充分利用CXL内存中的nt存储。

最近关于CXL内存的研究通常是通过跨NUMA内存访问来模拟CXL内存访问延迟来进行的，即通过对主内存访问施加额外的延迟来进行。然而，根据我们的观察，跨NUMA仿真模型无法精确模拟CXL内存的以下特征：（1）当前CXL设备中有限带宽的影响（除非远程DIMM填充的通道数与CXL内存相同），（2）与跨NUMA访问相比，延迟更高的各种CXL内存实现（在延迟受限的应用程序中，延迟更大的影响变得更严重），以及（3）不同工作负载下的数据传输效率（即负载和非临时存储带宽）。

为了研究CXL内存对性能的影响，我们通过将应用程序的内存全部或部分绑定到CXL内存来探索。Linux提供了numactl程序，它允许用户（1）将程序绑定到特定的内存节点（membind模式），或（2）优先分配给内存节点，并仅在指定节点内存耗尽时将内存分配给其他节点（首选模式），或者将分配均匀地分布在一组节点上（交错模式）。

Linux内核中最近的一个补丁现在允许对内存节点之间的页面交错率进行细粒度控制。这意味着，例如，如果我们将DRAM:CXL比率设置为4:1，我们可以将20%的内存分配给CXL内存。为了研究CXL内存对应用程序性能的影响，我们针对一些应用程序调整了这个交织比率。此外，我们禁用了NUMA平衡，以防止页面迁移到DRAM。

使用这种异构内存方案的这些应用程序的性能应该作为大多数内存分层策略的准则。这是因为与加权循环分配策略相比，所提出的优化至少应该表现得同样好。

Redis是一种在业界流行并广泛使用的高性能内存键值存储。我们使用YCSB来测试Redis在不同内存分配方案下的性能，方法是将其内存固定到CXL内存、DRAM或分布在两者之间。为了评估系统性能，我们在YCSB客户端中执行了多个工作负载，同时限制每秒查询（QPS）。具体来说，我们测量了两个指标：（1）查询中第99个百分点的尾部延迟，以及（2）最大可持续QPS。除了工作负载D之外，所有工作负载都对请求使用统一的分布，从而确保最大限度地增加内存压力。我们还微调了交织比（DRAM:CXL），以将一定量的内存卸载到CXL，在不同的实验中使用了30:1（3.23%）和9:1（10%）等比例。

我们在图6中的结果表明，当Redis纯粹在CXL内存上运行时，在低QPS（20k）下，p99尾部延迟存在显著差距。这一差距在55k QPS之前保持相对恒定，此时YCSB客户端无法到达目标QPS，导致尾部延迟突然增加。当Redis 50%的内存分配给CXL内存时，p99尾部延迟介于纯DRAM和纯CXL内存之间。尽管50%CXL内存Redis直到65k才使其QPS饱和，但尾部延迟在55k左右激增。最后，DRAMMRedis表现出稳定的尾部延迟，其QPS在80k左右饱和。

图6:Redis p99延迟。使用YCSB工作负载A进行测试（50%读取，50%更新）。50/100%-图例中的R/U表示50/100%Redis内存在CXL内存上运行时的读取/更新延迟

我们认为，尾部延迟差距归因于Redis查询的超低响应延迟，使这些μs级响应的延迟对内存访问延迟高度敏感。这与我们在第4.2节中给出的延迟测量结果非常相关，其中CXL内存访问延迟范围从数百到1000纳秒，比DRAM高2-4倍。然而，中间计算和缓存命中将延迟差异（就应用程序尾部延迟而言）降低到QPS饱和点之前的约2倍。

另一方面，CXL内存Redis可以提供的最大可持续QPS（图7）与第4.3.2节中观察到的随机块访问带宽相关，其中与本地-DDR5或远程-DDR5相比，CXL存储器的单线程加载/存储带宽要低得多。

图7:Redis最大QPS。测试具有各种CXL内存配置的最大可持续Redis QPS。图例表示Redis内存分配给CXL内存的百分比。YCSB工作负载D默认读取最近插入的元素（lat），但我们也用Zipfian（zipf）或uniform（uni）分布中的读取请求测试了该工作负载，以查看对访问位置的影响。这里省略了工作负载E，因为它是范围查询。

单线程随机访问带宽受内存访问延迟的限制，其中单线程内的数据依赖性使CPU中的负载存储队列难以饱和。此外，图7显示了一种趋势，即分配给CXL的内存更少（CXL内存百分比降低），在测试的所有工作负载中都能提供更高的最大QPS，但这些都无法超过纯粹在DRAM上运行Redis的性能。在这种情况下，内存交错无法提高单个应用程序的性能，因为与CXL内存的交错总是会引入更高的访问延迟。请注意，当前的CXL内存设置是基于FPGA的，其真正优点在于其灵活性。我们预计基于ASIC的CXL存储器将提供相对较低的访问延迟，从而提高延迟受限应用程序的性能。

图8:DLRM嵌入减少吞吐量。使用8通道DRAM和CXL内存进行测试；吞吐量与线程数（左）；32个线程时标准化为DRAM的不同内存方案的吞吐量（右）

深度学习推荐模型（DLRM）已在行业中得到广泛部署。嵌入缩减是DLRM推理中的一个步骤，已知其内存占用率很高，占用推理延迟的50%-70%。我们在DRAM、CXL内存和交错内存上测试了嵌入缩减，设置与MERCI相同。

图8中的结果显示，随着线程数的增加，在每个方案上运行DLRM推理都是线性的，并且斜率不同。DDR5-R1和CXL存储器的总体趋势相似，这与第4.3.2节中的观察结果一致，其中DDR-R1和CXL内存在访问粒度较小时具有相似的随机加载/存储带宽。内存交错的两个点（CXL内存上的3.23%和50%）如图8所示。随着我们将交错到CXL的内存量减少，推理吞吐量也会增加。然而，我们再次观察到，即使将3.23%的内存分配给CXL，推理吞吐量也无法与纯粹在DRAM上运行的吞吐量相匹配。还要注意，纯DRAM推理吞吐量呈线性扩展，其线性趋势似乎扩展到32个线程之外。结合这两个观察结果，我们可以得出结论，8通道DDR5内存可以在32个线程之外维持DLRM推断。

图8:DLRM嵌入减少吞吐量。使用8通道DRAM和CXL内存进行测试；吞吐量与线程数（左）；32个线程时标准化为DRAM的不同内存方案的吞吐量（右）

为了演示应用程序受内存带宽限制的场景，我们测试了SNC模式下的推理吞吐量。回想一下，英特尔在SPR中引入了子NUMA集群功能，其中小芯片被拆分为四个单独的NUMA节点，每个NUMA节点上的内存控制器独立于其他节点工作。通过在一个SNC节点上运行推理，我们有效地将推理限制在两个DDR5通道上运行，使其具有内存限制。

图9展示了在SNC模式下运行推理的结果，CXL内存以与之前所有实验相同的方式交错。图中的绿色条显示了SNC上的推理吞吐量，它在24个线程后停止线性缩放。在28个线程中，推理受到两个内存通道的限制，并且将内存交织到CXL会产生略高的推理吞吐量。这种趋势持续存在，在32个线程中，将20%的内存放在CXL上，与SNC情况相比，推理吞吐量增加了11%。未来，我们预计CXL设备的带宽将与本机RAM相当，这将进一步提高内存带宽绑定应用程序的吞吐量。

图9:DLRM嵌入缩减吞吐量

DeathStarBench（DSB）是一个开源基准套件，旨在评估系统上微服务的性能。它使用Docker来启动微服务的组件，包括机器学习推理逻辑、web后端、负载均衡器、缓存和存储。DSB为社交网络框架提供了三个单独的工作负载和一个混合的工作负载。图10显示了撰写帖子、读取用户时间线和混合工作负载的第99个百分点的尾部延迟。我们省略了读取home timeline的结果，因为它不在数据库上操作，因此与用于数据库的内存类型无关。在我们的实验中，我们将具有高工作集大小的组件（即存储和缓存应用程序）固定到DDR5-L8或CXL内存中。我们将计算密集型部分留在DDR5-L8。这些组件的内存细分如图10所示。

图10:DeathStarBench p99延迟和内存细分。工作负载：撰写帖子（左）、读取用户时间线（左中）、混合工作负载（右中）、按功能划分的内存细分（右）。混合工作负载有60%读取主页时间线，30%读取用户时间线，10%撰写帖子。

图10中的结果显示，在撰写帖子的情况下存在尾部延迟差异，而在读取用户时间线和混合工作负载的情况下几乎没有差异。请注意，DSB中的尾部延迟为毫秒级，远高于YCSB Redis。

当我们分析撰写帖子和读取用户时间线的轨迹时，我们发现撰写帖子涉及更多的数据库操作，这给CXL内存带来了更大的负载。同时，读取用户时间线的大部分响应时间都花在了nginx前端。这使得较长的CXL内存访问延迟可以在计算密集型组件中分摊，从而使尾部延迟对数据库访问延迟的依赖性大大降低。

最后，混合工作负载显示了真实社交网络的模拟用例，总体而言，大多数用户阅读了一些用户撰写的帖子。尽管在混合工作负载中，随着QPS的增加，将数据库固定到CXL内存会显示出略高的延迟，但总体饱和点类似于在DDR5-L8上运行数据库。

DSB的结果提供了CXL内存的一个有趣的用例，即只要计算密集型组件保留在DRAM中，以低需求率运行的缓存和存储组件就可以分配给较慢的CXL内存，并且应用程序的性能基本保持不变。

鉴于CXL内存的独特硬件特性，我们在充分利用CXL内存方面提供了以下见解。

将数据从CXL内存移出或移动到CXL内存时，请使用非临时存储或movdir64B。如第4节所示，不同的x86指令在访问CXL内存时表现出显著不同的性能，这是由于CPU核心的微体系结构设计和CXL内存的固有行为造成的。考虑到CXL内存的使用情况（例如，内存分层），短期数据重用的可能性不大，为了实现更高的数据移动吞吐量并避免污染宝贵的缓存资源，我们建议在相应的软件堆栈中优先考虑nt store或movdir64B指令。请注意，由于nt store和movdir64B都是弱排序的，因此需要使用内存围栏来确保数据已被写入。

限制并发写入CXL内存的线程数。如前所述，CXL内存的性能取决于CPU和设备控制器。对于并发CXL内存访问尤其如此，因为争用可能发生在多个位置。尽管CXL存储器控制器的当前基于FPGA的实现可能会限制内部缓冲区大小，从而限制动态存储指令的数量，但我们预计，在纯基于ASIC的CXL存储器设备上仍然存在该问题。最好在CPU软件端有一个集中的通信存根来进行数据移动。我们建议CXL内存应由操作系统或专用软件守护程序管理，而不是由所有应用程序管理。

使用Intel DSA进行从CXL内存到CXL内存的大容量内存移动。当在常规DRAM和CXL存储器上传输大量数据时，前两个见解可能仍然不足，因为它们消耗了大量的CPU周期，并且仍然具有有限的指令/存储器级并行性。我们发现，与前代产品相比，Intel DSA具有高吞吐量、灵活性和更少的限制，可以很好地进一步提高此类数据移动的性能和效率。这在分层内存系统中尤其有用，因为分层内存系统的数据移动通常以页面粒度（即4KB或2MB）进行。

使用NUMApolices和其他分层内存方法交错内存，以便在所有DRAM和CXL通道上均匀分配内存负载。除了将CXL存储器用作较慢的DRAM或较快的SSD（例如，存储器分层）之外，CXL存储器还可以与常规存储器通道交织，以增加总存储器带宽，尤其是当CXL存储器设备作为更多的存储器通道（从而更具可比性的存储器带宽）时。仔细选择交错百分比/策略可以在很大程度上缓解预期的性能下降。

避免在CXL内存上运行具有μs级延迟的应用程序。CXL内存相对较长的访问延迟可能会成为需要以精细时间粒度（μs级）进行即时数据访问的应用程序的主要瓶颈。Redis就是这样一个例子——由于CXL内存导致的延迟数据访问将积累到端到端查询处理的重要价值。这种类型的应用程序仍然应该考虑将数据固定在更快的介质上。

微服务可能是CXL内存卸载的一个很好的候选者。微服务架构由于其灵活、便于开发、可扩展和敏捷，已成为当今数据中心互联网和云服务的主流开发方法。然而，与传统的单片应用程序相比，它的分层和模块化设计确实带来了更高的运行时开销。这样的表征使其对底层高速缓存/存储器配置和参数不那么敏感。我们对DSB的研究（见第5.3节）也证明了这一点。我们设想，很大一部分微服务数据可以卸载到CXL内存，而不会影响其延迟或吞吐量性能。

利用可编程CXL内存设备探索在线加速的潜力。鉴于上述见解，那些适合CXL内存卸载的应用程序可能对数据访问延迟不太敏感。这为CXL内存设备内的内联加速逻辑提供了更多的设计空间——尽管这种加速可能会给数据访问增加额外的延迟，但从目标应用程序的端到端角度来看，这种开销是不可见的。因此，我们仍然提倡基于FPGA的CXL存储设备，因为它们具有灵活性和可编程性。

从分析的应用程序中，我们根据在CXL内存上运行时的性能确定了两种类型的应用程序：带宽受限和延迟受限。

内存带宽受限的应用程序通常会经历吞吐量的次线性增长，超过一定的线程数。尽管在CXL内存上运行Redis和DLRM推理都会产生较低的饱和点，但应该明确区分两者，只有DLRM推理是带宽受限的应用程序。单线程Redis受到CXL内存更高延迟的限制，这降低了Redis的处理速度。

内存延迟受限的应用程序即使将少量工作集分配给延迟较高的内存，也会感知到吞吐量下降。在数据库的情况下，当在CXL内存上运行时，即使QPS离饱和点很远，它们也可能显示出尾部延迟间隙。Redis和memcached等在μs级延迟下运行的数据库在纯CXL内存上运行时受到的惩罚最大。相比之下，具有计算层的毫秒级微服务显示出将内存卸载到CXL内存的良好用例。

然而，在这两种情况下，在传统的CPU连接的DRAM和CXL内存之间使用交错内存可以减少较慢的CXL内存在吞吐量（第5.2节）和尾部延迟（第5.1节）方面的损失。这种循环策略应该作为分层内存策略的基线。

随着存储器技术的快速发展，除了基于常规DDR的DRAM之外，数据中心还出现了许多新型存储器，每种存储器都有不同的特点和权衡。这些包括但不限于持久存储器，如Intel Optane DIMM，基于RDMA的远程/分解存储器，甚至字节可寻址SSD。尽管CXL内存已经被广泛研究和分析，但作为内存层中的一个新成员，其性能特征和指标仍不明确。

自2019年概念提出以来，CXL已经被许多研究人员讨论过。例如，Meta设想使用CXL内存进行内存分层和交换；微软构建了一个用于内存分解探索的CXL内存原型系统。他们中的大多数人使用NUMA机器来模拟CXL内存的行为。Gouk等人在基于FPGA的RISC-V CPU上构建了CXL存储器原型。与之前的研究不同，我们是第一个在商品CPU和CXL设备上进行CXL内存研究的，既有微基准测试，也有实际应用。这使我们的研究更加现实和全面。

CXL已经成为未来的设备互连标准，具有丰富的有用功能，而CXL内存就是其中的一个重要功能。在这项工作中，基于最先进的实际硬件，我们使用微基准和实际应用程序对CXL内存进行了详细的表征分析。通过对CXL存储器行为的独特观察，我们还为程序员提供了一些使用指南，以更好地利用CXL内存。我们希望这项工作能够促进CXL内存生态系统的开发和采用。

*免责声明：本文由作者原创。文章内容系作者个人观点，半导体行业观察转载仅为了传达一种不同的观点，不代表半导体行业观察对该观点赞同或支持，如果有任何异议，欢迎联系半导体行业观察。

今天是《半导体行业观察》为您分享的第3368内容，欢迎关注。