本文翻译自技术白皮书《CXL Memory Expansion: A Closer Look on Actual Platform》
由于本文篇幅较长，如果您想下载我整理校对过的中文版 pdf 文档，也可以在关注本微信公众号之后，从后台对话框发消息 CXL1129 来获取分享链接。
CXL 内存的驱动因素
数据密集型工作负载的激增，导致计算系统需要处理的数据量大幅增加。这种不断拓展的数据环境，迫切需要具备更大容量和更高带宽的内存解决方案。然而，要确保当前系统能够满足应用性能方面不断增长的需求，还必须克服诸多挑战。
挑战 1：遭遇内存墙问题
内存墙问题依然对系统性能构成根本性挑战，近年来，CPU 核心的扩展速度已经超过了每核心内存容量及带宽的扩展速度。如果这种趋势持续下去，严重依赖内存的工作负载将会因数据传输而遇到瓶颈，实际上就是触及了性能障碍。
CPU 厂商试图通过增加每个插槽的内存通道数量来解决这一问题。然而，增加更多内存通道需要在引脚数量以及布线复杂度方面付出巨大代价，这使得继续增加通道数量以跟上越来越高的核心数量变得颇具挑战性。此外，DRAM（动态随机存取存储器）制造商在按照与核心数量增长相匹配的速度提升内存芯片密度方面也面临诸多挑战。为通过其他方式增加容量，人们已经对 2DPC（每个通道配备 2 个双列直插式内存模块）进行了探索，但由于信号完整性问题，这是以降低带宽为代价的。其他类型的内存封装技术，如 3D 堆叠，成本效益并不高。因此，内存日益成为系统内极为关键的瓶颈以及宝贵的计算资源。
图 1. a）CPU 和内存的发展历程以及对每核心带宽的影响。
b）内存容量和 CPU 核心数量的历史趋势。
挑战 2：内存层级中的延迟和容量差距
主内存与存储介质之间已经形成了显著的性能差距。在动态随机存取存储器（DRAM）和诸如固态硬盘（SSD）等存储介质之间的内存层级中存在着巨大的延迟差距。随着对数据需求的不断增长，复杂的工作负载期望有更大的内存容量来适配数据集。由于行业受技术挑战所限，一直无法按照需求以具有成本效益的方式扩展内存容量，处理大型数据集的数据密集型工作负载可能会经历过度的请求分页和 I/O 活动，这可能会导致数据访问延迟大幅增加以及性能降低。
挑战 3：数据中心总体拥有成本的增加
内存作为瓶颈的重要性日益凸显，这导致了服务器总体拥有成本（TCO）的增加。事实上，根据近期在大规模云计算系统上开展的研究 [1]，内存大约占到了服务器总成本的 50%。如前文所述，除了每个插槽存在限制之外，当前提高带宽的方法涉及提升数据速率，而扩大容量则是通过诸如 2DPC（每个通道配备 2 个双列直插式内存模块）或者提高 DRAM 密度等技术来实现的，而这些方法往往顾此失彼。另一种方法是通过添加更多 CPU 或者采用 3D 堆叠内存封装技术进行横向扩展，但这些方法会导致总体拥有成本大幅增加。
Compute Express Link™（CXL）内存：纵向扩展（Scale-up）的极具吸引力的替代方案
为助力缓解上述挑战，业界正迅速朝着一种新的高速一致性互连协议 ——Compute Express Link™（简称 CXL）汇聚。CXL 是一种开放式行业标准互连方式，它利用处理器、加速器、内存、存储以及其他 I/O 设备之间的高带宽、低延迟连接，提供一致性和内存语义。它通过提高系统中每核心的带宽和容量来进行 Scale-up 纵向扩展，从而有助于应对上述挑战。
CXL 正被更快地采用，因为它为 PCI Express（PCIe）物理层引入了 load / store 语义，能够以可与远程非一致性内存访问（NUMA）节点 DRAM 内存相媲美的访问延迟来扩展容量和带宽。这解决了处理器引脚数量方面的挑战，并避免了仅仅为获取额外带宽和容量而添加新处理器所带来的总体拥有成本问题。随着 CXL Type-3 内存扩展（CXL.mem）的引入，可以采用新的内存模式来支持不断增长的内存容量需求，它还能降低具有相似性能目标的系统配置的数据中心总体拥有成本。
连接 CXL 的内存设备带来了两个重要的价值主张，如下所述：
・通过异构交错实现 CXL - 内存带宽扩展（在软件层面体现）。
・通过内存分层实现 CXL - 内存容量扩展，通常借助基于深入研究的 NUMA 抽象概念和接口构建的操作系统层面的支持。
本文旨在展示 CXL 如何通过在服务器 DIMM 插槽之外增加内存带宽和容量，来帮助克服现有系统面临的挑战。我们从在支持多个 CXL 内存模块（CMM）的实际服务器平台上执行数据密集型和高性能工作负载所收集的实验数据的角度，来审视 CXL 所带来的价值主张。这与之前大多在早期原型或仿真 / 模拟框架上进行的 CXL 内存扩展实验形成了对比，那些实验未必能捕捉到真实系统中运行实际工作负载的真实 CXL 设备的实际行为。在真实平台和真实 CMM 上运行工作负载是朝着展示 CXL 在数据中心的价值主张迈出的重要一步。
系统详情与配置
图 2. AMD 平台和美光 CZ120 CXL 内存模块（CMM）的高级产品详情。
图 2 展示了由面向云计算的 AMD EPYC™ 9754 CPU 所支持的美光（Micron™）CMM 的详细信息，AMD EPYC 9754 CPU 可为计算密集型的云计算服务器提供多达 128 个核心。AMD EPYC 9754 围绕更高吞吐量的工作负载进行了优化，它最多支持 12 个内存通道，若每个通道采用 64GB 内存模块，则总容量可达 768GB，若每个通道采用 96GB 内存模块，则总容量可达 1152GB。
随着 EPYC 9754 核心数量的增加，每核心的容量和带宽被限制在 6GB / 核心（每个通道采用 64GB 内存模块时）或 9GB / 核心（每个通道采用 96GB 内存模块时），且在假设数据传输速率为 4800 MT/s（兆传输每秒）的情况下，带宽为 3.6 GBps（千兆字节每秒）/ 核心。在添加了美光的 4 个容量各为 256GB 的 CZ120 CXL 内存模块后，系统每核心的容量和带宽分别增加到 14GB / 核心（采用 64GB 内存模块时）或 17GB / 核心（采用 96GB 内存模块时）以及 4.85 GBps / 核心。
具体来说，对于采用 64GB 内存模块的系统，相较于原生 DRAM 配置（每个通道 64GB DDR5 内存），内存容量增加了 133%，与未采用 CXL 的系统相比，带宽扩展了 33%。虽然系统开发人员可以自由选择任何可用的本地 DRAM 模块容量，但图 2 着重展示了一种可能的配置。
图 3. AMD 平台和美光 CZ120 CXL 内存模块（CMM）的高级产品详情。
CZ120 CXL 内存模块（CMM）是美光第一代 CXL 内存扩展产品。每个 CMM 提供一个 PCI Express（PCIE）第 5 代 x8 链路宽度。它有两个作为后端介质连接的 DDR4 内存通道，每 个 CMM 可提供高达 256GB 的容量，并针对 2-读：1-写的流量模式设定了有竞争力的带宽，且引脚到引脚的空载延迟较低。图 3 着重展示了 CZ120 产品的关键差异化特性。
CXL 的软件与硬件支持
为实现最佳应用性能，内存层级策略侧重于将“热”内存区域（频繁复用的数据）存储在更靠近 CPU 的主内存中，而将“冷”内存区域（不常复用的数据）移至存储介质，存储介质通常容量更大但速度较慢。然而，由于主内存和存储介质之间存在较大的延迟差距，在两者之间移动数据的过程会导致显著的性能损失。这就为新增一层内存（far memory）创造了机会，这层内存具备更高的容量以及与 near memory（近内存）相当的访问延迟。
基于这样的特性，CXL 可置于主近内存和存储介质之间，从而扩展内存层级。理想情况下，目标是将“热”数据存储在近主内存中，“温”数据存储在 CXL 上，“冷”数据存储在存储介质中，以此优化应用性能。数据的“热度”通常由其在特定工作负载中的使用频率、近期使用情况或复用情况等指标来确定。
系统软件开发者，尤其是 Linux 社区的开发者，一直在提升跨非一致性内存访问（NUMA）域和内存层级运行的应用程序的性能方面取得重要进展 [2]。配备 AMD EPYC 9754 处理器的 AMD Bergamo 平台提供了对 NUMA 域的广泛可配置性。它支持每个插槽对应一个 NUMA 节点（NPS）的概念，以提升不同工作负载的性能。支持的 NPS 设置如下：
・NPS1—— 每个插槽处于单个 NUMA 域中，插槽内的所有核心及其关联内存在一个 NUMA 域中与插槽相连，而所有 CXL 内存模块（CMM）构成另一个 NUMA 域。
・NPS2—— 每个插槽被划分为两个 NUMA 域，每个 NUMA 域连接 6 个内存通道，所有 CMM 构成第 3 个 NUMA 域。
・NPS4—— 每个插槽被划分成四个 NUMA 域。每个 NUMA 域有 3 个内存通道，内存访问在每个域内的这三个内存通道间交错进行。所有 CMM 交错在一起构成第 5 个 NUMA 域。
如图 4 所示，基于 CXL 的内存扩展器在 Linux 系统中表现为一个仅含内存或无 CPU 的新 NUMA 节点。
在本文中，我们将在上述非一致性内存访问（NUMA）配置的背景下，考察 CXL 内存扩展的各种价值主张。具体而言，本文分析了不同设置（即 NPS1、NPS2 和 NPS4）对基于软件的异构交错的影响。这些设置能够实现软件页面级交错，以便针对特定工作负载分配页面，使其能按照 50% DRAM（动态随机存取存储器）/50% CXL（NPS1）、66% DRAM/34% CXL（NPS2）以及 80% DRAM/20% CXL（NPS4）的比例在本地 DRAM 和 CXL NUMA 节点之间进行分配。关于这些设置实际应用的更多详细内容将在 CloverLeaf 分析章节详细阐述。
图 4. a）AMD EPYC 和美光 CXL 内存模块（CMM）卡划分成非一致性内存访问（NUMA）域的情况：（i）NPS1，（ii）NPS2，以及（iii）NPS4。
b）作为页面热度以及介质访问速度体现的内存分层情况。
在通过内存分层进行内存容量扩展的背景下，NPS1 配置是一种合理的选择。在此配置中，每个 CPU 插槽及其本地 DDR 模块共同构成第一个 NUMA 域，而全部四个 CXL 内存模块（CMM）一起构成第二个 NUMA 域。NUMA 域是基于访问延迟来划分的，连接到 CPU 插槽的本地动态随机存取存储器（DRAM）构成访问速度更快的 “近” NUMA 域，而由于 CXL 内存具有更高的访问延迟，其充当相对较慢的 “较远” NUMA 域。
像 Linux 这样的现有操作系统已经具备执行 NUMA 分层 / 平衡的能力。这使得能够将热页面（频繁访问的页面）放置到更近的 NUMA 域（本地 DRAM）中，将温页面（适度访问的页面）和冷页面（不常访问的页面）放置到较远的 NUMA 域（CXL）中，而将最冷的页面放置到访问延迟最高的内存中（通常是固态硬盘，即 SSDs）。
简而言之，CXL 内存扩展能够利用现有的硬件和软件体系轻松实现支持，无需对现有设置进行任何更改。
工作负载基准测试描述
以下这些工作负载已被选用来评估连接 CXL 的动态随机存取存储器（DRAM）在整体系统性能方面的价值主张。这些工作负载对诸如容量、延迟和带宽等不同指标较为敏感。图 5 展示了由 AMD uProf 性能分析工具包 [3] 所报告的这些工作负载的微架构自顶向下分析情况。
图 5.不同工作负载的微架构分析和带宽利用率分析。
・微软 SQL Server（MSSQL） + TPC-H™（联机分析处理，OLAP）—— 一款运行联机分析处理（OLAP）基准测试套件的数据库软件。它响应与业务相关的查询，并对存储在数据仓库中的大量数据进行分析 [4]。自顶向下的微架构分析（见图 5）显示，TPC-H 工作负载使 CPU 流水线槽位有三分之一出现停滞，且大部分停滞是由后端内存受限导致的。由于该工作负载仅消耗系统中可用的总 DRAM 带宽的 50%，它不受带宽限制，相比带宽而言，对内存延迟更为敏感。由于此工作负载要处理大量数据，并且在线查询处理需要多个并行任务，所以 CXL 所提供的额外内存容量很有价值，有助于将应用程序执行扩展到高核心数量，同时最大限度地减少输入 / 输出（IO）停滞情况。
・三叶草（CloverLeaf，高性能计算）—— 一款小型应用程序，它使用显式二阶精度方法在笛卡尔网格上求解可压缩的欧拉方程 [5]。每个单元格存储三个值：能量、密度和压力，并且在每个单元格角点存储一个速度矢量。图 5 中对该工作负载的微架构分析着重指出，几乎约 95% 的 CPU 流水线处于停滞状态，且几乎所有停滞都是由后端内存受限导致的。此外，内存带宽利用率数据显示，该工作负载几乎消耗了全部的 DRAM 带宽。这表明三叶草（CloverLeaf）是一个对带宽高度敏感的工作负载。
・基于 Apache Spark™ 机器学习的 Support Vector Machine（SVM）（大数据工作负载）——Apache Spark 是一个用于大数据和机器学习工作负载的开源数据处理框架。Spark 主要提供弹性分布式数据集（RDD）作为其核心抽象概念。弹性分布式数据集（RDD）是分布在各个计算节点上的元素的分区集合，能够实现对数据的并行操作。斯帕克（Spark）机器学习（ML）支持向量机（SVM）用于对机器学习数据集进行训练和回归 [6]。对该工作负载的自顶向下分析（见图 5）表明，它是一个受内存限制的工作负载，在处理大型数据集时对内存延迟和内存容量较为敏感。
工作负载性能分析
用于运行这些工作负载的硬件配置情况如表 1 所示。
表 1 运行工作负载的硬件配置
以下各小节将详细描述这些工作负载的性能分析及结果，包括针对每个工作负载所采用的实际内存扩展策略。作为一种通用方法，每次运行都会收集仅使用 DDR5 配置（768GB 或 1152GB）时的工作负载性能指标，然后在 DDR5 搭配 4 个 CXL 内存模块（CMM）的设备上重复相同的实验（其中本地 DDR 贡献 768GB 或 1152GB，CMM 贡献 1024GB）。对于每个配置数据点，实验至少重复三次，并将这些数值的中位数作为结果考量。
MSSQL + TPC-H（联机分析处理）
实验设置
TPC-H 工作负载运行在微软 SQL Server 数据库上，其拥有一个以列式格式存储的 3TB 数据集（规模因子为 3000）。该数据集是由 HammerDB 基准测试软件 [8] 生成的。此工作负载采用 NPS1 设置来执行，即将本地内存通道视为一个非一致性内存访问 （NUMA）域，而四个 CXL 内存模块（CMM）构成另一个 NUMA 域。在执行该工作负载期间，未对应用软件做任何更改。在执行该工作负载时遵循了 [9] 中所述的 Linux 操作系统上的性能最佳实践，这些最佳实践确保了该工作负载在 Linux 平台上执行时能达到最佳性能和效率。
为评估 TPC-H 工作负载的性能，采用了查询吞吐量这一指标。吞吐量以每小时完成的查询数量来衡量，它反映了系统有效处理大量工作负载请求的能力。这里会给出单流以及多流（共 8 个流）情况下的结果。每个流并行运行，按照 TPC-H 标准规范 [4] 为每个流给定的特定查询顺序依次运行一组 22 个查询。
配备 1 个 NVMe 驱动器运行单流 Power Test 的关键发现
图 6. 采用 12 * 64GB DRAM和 1 个 4 通道 NVMe 固态硬盘（相当于大约每核心 60MB/s）的 MSSQL + TPC-H power test 数据。
图 6 展示了单流情况下的结果，即针对仅使用本地 DDR 或者本地 DDR + CXL（内存扩展）且采用 64GB 内存模块配置的、运行在微软 SQL Server 上的 TPC-H 的单次 Power Test 结果。纵轴显示的是归一化的查询加速比，横轴表示流的数量。
数据显示，与仅使用 DDR 的配置相比，DDR + CXL 配置在单流情况下实现了 70% 的加速，在 8 个流配置下实现了 500% 的加速，这看上去好得令人难以置信。经过进一步验证，原因归结于在仅使用 DDR 的系统中单个 NVMe SSD 的带宽饱和问题。系统中使用的 NVMe SSD 最大可持续带宽为 8GB/s。正因为如此，DDR 的性能受到了限制，数据表明仅该数据集的一个流就足以使 NVMe SSD 的带宽达到饱和。所以，由于请求分页的缘故，仅使用 DDR 的配置对 NVMe SSD 有更多访问需求，但其性能相比于本地 DDR + CXL 配置要差得多。单个 NVMe SSD 无法满足来自 DDR 内存的请求分页的带宽需求。
为了消除等式中 NVMe SSD 带宽这一瓶颈，已将系统配置更新为使用 8 个 NVMe SSD，并生成了后续的结果。
配备多个 NVMe 驱动器且采用 64GB 本地 DDR 模块的多流（Multi-Stream）关键发现
图 7. 在配备 12 * 64GB DRAM 以及多个固态硬盘（每核心> 300MB/s）的MSSQL 服务器上运行的多流 TPC-H 测试情况：（a）查询加速比，
（b）IO事务数量比值
图 7a 重点展示了相对于使用 8 个 NVMe SSD 和 64GB 本地 DDR 模块且流数量相同情况下的查询处理加速因子。将仅使用 DDR 配置（768GB）在不同并行工作负载流数量下的加速因子以及输入 / 输出（IO）事务减少量，与采用 DDR + CXL 配置（1792GB）且运行相同数量流的情况进行了对比。
在这两种配置中，工作负载大小都大于系统内存大小。在图 7a 中，随着流的数量从 1 增加到 20，对于相同数量的工作负载流，DDR + CXL 配置的查询执行速度相对于仅使用 DDR 的配置显示出约 3.2 倍的增长。对于单流测试，改进幅度较低，约为 1.23 倍。图 7b 显示，借助 CXL 形式的额外内存，相对于仅使用本地 DDR 的系统配置，单流测试的 IO 事务数量下降了 44%，8 流测试下降了 88%。这也凸显了 8 流工作负载查询速度提升 1.96 倍的关键原因。
（c）内存占用量比值
图 7c 展示了不同配置中所使用的内存量。内存占用率比值衡量的是 DDR + CXL 配置与仅使用 DDR 配置下工作负载使用内存量之间的比率。在考虑单流时，内存占用量适度增加 42% 就会使 IO 事务显著减少 44%。这种减少最终使得查询速度提升了 23%。在 8 个和 20 个并行工作负载流的情况下，内存占用量分别增加 128% 和 141%，会使 IO 事务分别减少 88% 和 89%。这种减少分别使得 TPC-H 工作负载的 8 流和 20 流的查询速度提升了 96% 和 222%。
图 8. 相对于仅在 DRAM（12 * 64GB）及多个固态硬盘（每核心 > 300MB/s）配置上单流运行的多流 TPC-H 查询执行加速比
图 8 突出显示了与图 7a 相同的数据点，仅有一处改变，即不同并行流运行的执行加速情况是以在本地 DRAM 上单流运行所获得的结果进行归一化的（不同的倍数计算参考点）。以这种形式呈现数据能让我们了解在扩展工作负载时的饱和点。
从图 8 中可以看出，仅使用 DDR 的配置在 8 个并行工作负载流时性能达到峰值。此后流数量的任何增加都会因内存争用而导致性能下降。由 DRAM 和 CXL 组成的软件分层内存设置使我们能够将 TPC-H 工作负载扩展到 16 个并行流，此后性能达到饱和，即便工作负载流数量继续增加也不会再有性能提升。内存争用效应在 24 个流之后出现。
图 8 还表明，如图 7a 所示，相对于 20 个流的 DRAM 配置性能大幅跃升 3.22 倍的关键原因，主要是由于仅使用 DRAM 配置在 20 个流时性能下降所致。仅使用 DRAM 的配置在 8 个并行流时性能达到峰值。仅使用 DRAM（8 流）与使用 DRAM + CXL（16 流）配置之间的峰值性能差值为 2.3 倍。
配备多个 NVMe 驱动器且采用 96GB 本地 DDR 模块的 Multi-Stream 关键发现
图 9. 在配备 12 * 96GB DRAM 以及多个固态硬盘（每核心 > 300MB/s）的微软 SQL Server（MSSQL）服务器上运行的多流 TPC-H 测试情况：（a）查询加速比
图 9 重点展示了在具备 8 个 NVMe 固态硬盘带宽以及 96GB 本地 DDR 模块的情况下，查询处理加速因子与流数量之间的关系。将仅使用 DDR 配置（1152GB）的加速因子以及 IO 事务减少量与 DDR + CXL 配置（2176GB）的相应情况进行了对比。在这两种配置中，都运行工作负载的多个并行流，以确保总数据集大小大于系统内存大小。
在图 9 中，随着流的数量从 1 增加到 20，相对于相同数量工作负载流的仅使用 DDR 的配置，DDR + CXL 配置的查询执行速度在 20 流时展现出最佳的相对执行加速，提升幅度达 69%。对于单流测试，改进幅度较低，约为 1.19 倍。
（b）IO事务数量比值
图 9b 显示，借助 CXL 形式的额外内存，相对于仅使用本地 DDR 的系统配置，8 流测试的 IO 事务数量下降了 70%，20 流测试下降了 83%。这也凸显了 8 流和 20 流工作负载查询速度分别提升 23% 和 69% 的关键原因。
（c）内存占用量比值
图 9c 展示了不同配置下所使用的内存量。归一化内存占用率比值衡量的是 DDR + CXL 配置与仅使用 DDR 配置下工作负载使用内存量之间的比率。在考虑 8 个并行流时，内存占用量增加 71% 会使 IO 事务显著减少 70%。这种减少最终使得查询速度提升了 23%。在 20 个并行流的情况下，内存占用量增加 89% 会使 IO 事务减少 83%。相对于仅在 DDR 配置上运行相同数量流时的性能，这种减少使得 TPC-H 工作负载的查询速度提升了 69%。
我们希望您关注单流数据，相对于相同数量工作负载流的原生 DDR 配置，单流数据显示查询速度提升了 19%，但 IO 操作仅减少 11%，而 8 流工作负载仅显示查询速度提升 23%，但 IO 操作减少了 70%。虽然这些数据是经过多次运行收集并取平均值的，确保了数据的真实性，但在某些特殊情况下很难确定确切的原因，因为工作负载的性能会随着原生 DDR 和 CXL 之间的内存容量分配、工作负载占用量以及并行流的数量而发生显著变化。
图 10. 相对于仅在DRAM（12 * 96GB）及多个固态硬盘（每核心> 300MB/s）配置上单流运行的多流 TPC-H 查询执行加速比。
图 10 突出显示了与图 9a 相同的数据点，但有一处改变，即不同并行流运行的执行加速情况是以在本地 DRAM 配置上单流运行所获得的加速值来计算比率（不同的归一化参考点）。以这种形式呈现数据有助于我们在引入 CXL 内存时评估扩展的价值主张。如图 10 所示，仅使用 DDR 的配置在 TPC-H 工作负载的 8 个并行流时性能达到峰值。相对于在本地 DDR 上单流运行的执行加速情况，在 8 个并行流达到峰值后便保持恒定。由 DRAM 和 CXL 组成的软件分层内存设置使我们能够将 TPC-H 工作负载扩展到 28 个并行流，此后性能达到饱和。
小结
图 11. 在 MSSQL 服务器上运行的多流 TPC-H 测试 —— 不同系统内存配置相对于仅单流 DRAM 配置（12 * 64GB）的查询加速比
图 11 对比了采用 64GB DDR 模块、96GB DDR 模块、搭配 1TB CXL 内存的 64GB DDR 模块以及搭配 1TB CXL 内存的 96GB DDR 模块时多流的执行加速情况，该对比是以仅采用 64GB DDR 模块配置下单流工作负载运行时所观察到的查询加速比为参照的。
这些数据有助于我们确定这样一个事实：相较于将本地内存从 64GB 的 DDR 模块升级到 96GB 的 DDR 模块，CXL 有助于进行容量扩展并降低总体拥有成本。此外，与仅采用 96GB 模块的 DDR 配置相比，添加 CXL 卡能让我们更有效地进行扩展。
这一点可以通过以下事实得到验证：采用 64GB DDR 模块作为本地 DRAM 配置并搭配 CXL 的方案，其性能比仅采用 96GB DDR 模块的 DRAM 配置高出 1.6 倍，而且在 16 或 20 个并行工作负载流时查询加速性能达到饱和，而仅采用 DDR 的配置在并行运行 8 个 TPC-H 工作负载流时性能就达到饱和了。
从图 11 可以看出，两种仅采用 DDR 的配置在 8 个并行的微软 SQL Server（MSSQL）TPC-H 流时查询加速达到峰值，而搭配 CXL 的 64GB DDR 模块（总容量 = 1796GB）在 16 个流时查询加速达到峰值，搭配 CXL 的 96GB DDR 模块（总容量 = 2192GB）在 28 个并行的 TPC-H 流时查询加速达到峰值。
CLOVERLEAF（三叶草，高性能计算）测试
实验设置
该工作负载在 NPS1、NPS2 和 NPS4 这几种设置下运行，并且在每种情况下，所有 CXL 内存模块（CMM）都构成一个单独的非一致性内存访问（NUMA）域。所使用的输入文件是来自官方发布包中的 “clover_bm1024_short.in”。
该工作负载通过 Linux 系统中的 “numactl” 命令并采用轮询交错策略来运行。因此，这实现了 50% - 50%（NPS1）、66% - 34%（NPS2）以及 80% - 20%（NPS4）的交错比率，其中第一个数字表示分配给本地 DDR 的物理内存页面数量占比，第二个数字表示分配给 CXL 内存的物理内存页面数量占比。
关键发现
对于 CloverLeaf 工作负载，CXL 内存模块（CMM）被配置用于提供带宽扩展。对于此类工作负载，当基于 AMD EPYC 9754 且配备 12 个内存通道（每个通道采用 64GB 内存模块，时钟频率为 4800 MT/s）的平台通过 BIOS 被配置为 NPS4 设置时，可观察到最佳性能。采用 NPS4 设置时，本地 CPU 插槽被划分为四个非一致性内存访问（NUMA）域，每个 NUMA 域有 3 个本地 DDR 通道交错在一起，而四个 CXL 通道构成第五个 NUMA 域。
这确保了 80% 的内存分配在本地 DDR 通道上，20% 分配在 CXL 通道上。当仅使用本地 DDR 通道（不使用 CXL）时，在 NPS4 配置下，100% 的内存分配都在本地 DDR 通道上进行。这是一种使用异构内存的软件交错形式。
图 12. a）用于 DDR + CXL 设置的 NPS4 架构。
b）通过软件定义页面分配比率实现的 CloverLeaf 执行速度提升情况。
图 12b 中的结果展示了软件异构内存交错是如何助力提升高性能计算（HPC）工作负载性能的。数据显示，在交错比率为 80:20（其中 80 对应映射到本地 DDR 设置的物理页面百分比，剩余 20% 映射到 CXL 内存模块（CMM））的情况下，采用 12 个 64GB DDR 通道再加上 4 个 CMM 时，相较于仅使用 12 个 64GB DDR 通道，速度提升了 17%。
正如在图 4 中对工作负载的微架构自顶向下分析所确定的那样，CloverLeaf 是一个带宽密集型工作负载。添加 4 个 CMM 后，相对于时钟频率为 4800 MT/s 的 12 个 DDR 通道，带宽扩展了 33%。与原生 DRAM 相比，CXL 额外的空闲延迟劣势通过多个 CMM 所提供的带宽扩展得到了弥补。CloverLeaf 速度提升 17% 这一改进清晰地展示了通过软件异构交错实现 CXL 带宽扩展的价值主张。
即便将本地内存模块从 64GB 增加到 96GB，结果也会相同，因为像 CloverLeaf 这样的高性能计算（HPC）工作负载对内存容量并不敏感。
Spark 机器学习 SVM （大数据分析）
实验设置
该工作负载采用旨在通过内存分层实现容量扩展的 NPS1 配置来运行。原始数据集为 360GB，但 Spark 在数据处理过程中的内存占用量会增加，并且需要内存用于中间处理步骤，因此要利用比仅使用 DDR 配置更大的内存空间。
配备多个 NVMe 驱动器以及 64GB/96GB 本地 DDR 模块时的关键发现
图 13. 相对于仅使用 DDR 配置，Spark 机器学习在 DDR + CXL 情况下的执行速度提升情况：a）786GB DDR 与 1TB CXL；
b）1152GB DDR 与 1TB CXL
根据图 13a 所示，通过内存分层将 1TB 的 CXL 作为一个新的内存池纳入进来，与仅依赖 768GB 本地 DRAM 的配置相比，执行速度提升显著，达到了 2.21 倍。当在配备 1152GB 本地 DRAM 和 1TB CXL 内存的情况下运行相同工作负载时，相对于 1152GB 的本地 DRAM，执行速度提升为 1.66 倍。
凭借将像 RDD 这样的关键数据结构持久化存储在内存中的能力，Spark 利用了 CXL 所提供的扩展内存，从而能够在并行操作期间高效地复用数据。这种增强最终提升了整体的数据处理性能。缓存 RDD 是一种加速应用重复访问同一 RDD 的机制。如果不进行缓存或设置检查点，每次对某个 RDD 触发操作时，该 RDD 都会被重新求值。
小 结
图 14.a）Spark机器学习执行速度提升情况
（b）相对于仅 768GB DDR 配置的速度提升比率与内存容量增加情况。
Spark 机器学习工作负载对增量内存容量高度敏感。如图 14a 所示，不同的内存容量，即 1152GB（12 * 96GB 本地 DRAM）、1756GB（12 * 64GB 本地 DRAM + CXL）、2176GB（12 * 96GB 本地 DRAM + CXL），相对于以 768GB 本地 DRAM 为基准，执行速度提升分别达到了 1.61 倍、2.22 倍和 2.67 倍。
为了解该工作负载对通过 CXL 卡或者更高密度的本地 DRAM（96GB）所贡献的增量内存容量的敏感程度，图 14b 展示了相对于 768GB 本地 DRAM 的执行速度提升比例以及内存容量增加情况。数据显示，执行速度提升和内存容量增加情况相互重叠，由此可以得出结论：Spark SVM 对 CXL 内存增加的访问延迟不太敏感，并且工作负载性能会随着容量的增加呈线性提升。在 MSSQL 的 TPC-H 工作负载中并未观察到这种趋势。
结论
针对 CXL 的两个价值主张 ——CXL - 内存带宽扩展以及 CXL - 内存容量扩展，对不同工作负载进行的性能研究使我们得出以下结论。
CXL - 内存带宽扩展
像 CloverLeaf 这类对带宽敏感的工作负载，会使大部分 CPU 流水线槽位处于停滞状态，且超过 75% 的这些停滞是由后端内存受限导致的。CXL 内存能够借助基于软件的 DDR 与 CXL 内存之间的交错来助力带宽扩展。针对 CloverLeaf 的实验结果表明，当系统经过适当调优时，如果 CXL 将带宽扩展 33%，该工作负载能够获得高达 17% 的性能提升。
尽管结果显示相对于仅使用本地 DDR 的配置有 17% 的性能加速，但这种改进仅在 NPS4（非一致性内存访问节点划分方式）设置下可见。另一方面，NPS1 和 NPS2 相对于仅使用本地 DDR 的配置反而呈现出性能下降的情况。在以 4800 MT/s 运行的本地 DRAM 与 4 个 CXL 内存模块（CMM）之间的带宽比率约为 2.8 倍。如果由于本地 DDR 速度提升、CXL 与本地 DDR 通道数量变化等原因导致这些带宽比率改变，那么交错比率也需要相应改变。
CXL - 内存容量扩展
诸如 Spark 机器学习 SVM 和 运行在 MSSQL 上的 TPC-H 这类工作负载，会因来自 DDR 的请求分页而产生大量 IO 事务。当把 CXL 作为本地 DDR 的分层内存引入时，有助于显著减少 IO 事务的数量。温数据被放置在 CXL 内存模块（CMM）中，其距离本地 DDR 更近，访问延迟远低于访问 IO 介质的延迟。
TPC-H 单流分析表明，相对于仅由 64GB 模块构成的本地 DDR 配置，只进行 42% 的内存扩展时，IO 事务就能减少 44%，进而实现 23% 的性能加速。TPC-H 8 流分析显示，在内存占用量扩展 128% 的情况下，IO 事务下降了 88%，从而实现了 96% 的性能加速。
仅使用 DDR 的配置在 TPC-H 工作负载的 8 个并行多流时吞吐量达到饱和。在实验中使用 96GB 仅 DDR 模块时也能观察到类似趋势。然而，添加 CXL 内存相对于任何一种仅使用 DDR 的配置都能提升性能，并有助于增加工作负载并行流的数量。
性能的提升与内存容量的增加并非呈线性关系。这清楚地表明，当我们减少与存储介质之间的事务时，对容量或延迟敏感的工作负载能够在性能上获得极大的提升。在 Spark SVM 工作负载中也能看到类似趋势，不过有一点区别，即 Spark SVM 的执行速度提升与内存容量的增加呈线性关系。
重要的是要明白，不同的工作负载具有不同的特性，并且对诸如延迟、带宽和容量等指标有着不同的敏感度。诸如内存分层或内存交错之类的系统配置旨在为不同的工作负载提供最佳的价值主张。
参考内容
[1] Pond: CXL-Based Memory Pooling Systems for Cloud Platforms (https://arxiv.org/abs/2203.00241)
[2] TPP: Transparent Page Placement for CXL-Enabled Tiered-Memory (https://arxiv.org/pdf/2206.02...)
[3] AMD uProf: https://www.amd.com/en/develo...
[4] TPC-H Homepage: https://www.tpc.org/tpch/
[5] CloverLeaf Benchmark: https://www.amd.com/en/develo...
[6] Apache Spark SVM: https://spark.apache.org/docs...
[7] Intel MLC Documentation : https://www.intel.com/content...
[8] HammerDB benchmarking tool: https://www.hammerdb.com/
[9] SQL Server Linux Performance Best Practices: https://learn.microsoft.com/e...
原文链接
END
作者：
Micron: Vinicius Petrucci, Eishan Mirakhur, Nikesh Agarwal, Su Wei Lim, Vishal Tanna
AMD: Rita Gupta, Mahesh Wagh
编译：唐僧
原文：企业存储技术
推荐阅读
欢迎关注企业存储技术极术专栏，欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。
