重新审视 CXL 时代下的分布式内存

消息传递与分布式共享内存

随着摩尔定律增长的逐渐减缓，系统规模的水平扩展已经成为提升系统性能的关键策略。然而，这种扩展依赖于分布式系统架构的支持，而分布式编程的固有复杂性给构建高效、可靠及弹性的系统带来了严峻挑战。因此，简化分布式编程依旧是分布式编程框架追求的核心目标。

如图所示，在分布式编程领域，目前主流的编程范式主要分为两类：消息传递（Message Passing，MP）和分布式共享内存（Distributed Shared Memory，DSM）。DSM 范式因其提供一致的内存空间视图和抽象化的数据通信复杂性而更易于使用，这样的设计让分布式应用程序的能够直接编程就像在单机上进行多线程编程一样简单。然而，在实际应用中，较为直接但不太直观的 MP 模型却更为普遍。开发者对 MP 的偏好很大程度上基于这样一个假设：远程通信的高昂开销显著影响了 DSM 系统的性能。

但是随着网络和互联技术的飞速发展，研究者在逐渐改变对于该领域的看法，特别是随着 Compute Express Link（CXL）技术的推出，我们站在了一个重新思考传统分布式编程范式的新起点。这个技术突破促使我们必须重新评估 DSM 在现代分布式系统中的应用潜力。

从以太网到 RDMA 再到 CXL

从工业界将重心从以太网转移到远程直接内存访问（RDMA），再到当前对Compute Express Link（CXL）的关注，这一连串变迁标志着互连技术领域的一系列重大突破。RDMA 的广泛采用极大地革新了现代数据中心的构架，并对众多流行的分布式系统设计产生了深远影响，其中包括许多影响深远的数据库和存储项目。通过利用 RDMA，我们能够将远程数据访问的延迟从 100 多毫秒显著降低到微秒量级，同时提供类似本机内存的读/写接口，极大地减少了远程操作的成本。作为最前沿的互联协议，CXL 旨在提供高速且具备缓存一致性的跨物理节点数据传输。例如，DirectCXL[1] 将主机处理器与远程内存资源连接，支持加载/存储指令，其远程 CXL内存访问的延迟大约为 300 纳秒，与访问远程 NUMA 节点的延迟相媲美。CXL 2.0 的一个关键进步在于引入了内存池化功能，该功能可以构建全局内存资源池，以此优化内存的总体利用率。内存池化可以通过 CXL 交换机和内存控制器实现，便于内存资源的动态分配与回收。Pond 作为第一个满足云服务提供商需求的全栈内存池[2]，其基于 CXL 的内存池系统已在 Microsoft Azure 云平台上进行了小范围部署。至今，大部分主流云服务提供商都相继宣布了支持并研发基于 CXL 内存池的计划。

进一步地，已公布的 CXL 3.0/3.1 等规范版本，承诺将支持内存共享功能[3]。共享内存允许在多台机器间映射同一内存区域，在这样的配置下，硬件会自动管理不同机器并发访问产生的缓存一致性问题，从本质上实现了基于硬件的分布式共享内存模型。这一革命性的新功能为分布式计算的未来奠定了充满无限可能性的基石。

重温 CXL 时代 DSM 范式下的分布式应用

尽管 Compute Express Link（CXL）的规范版本已经发展至 3.1，实际的硬件实现却远未跟上规范的快速进步。但这正是一个在即将来临的 CXL 时代背景下，对消息传递（MP）和分布式共享内存（DSM）之间区别重新审视的绝佳时机，关键在于理解它们的差异性，并识别最适合它们的应用场景。这两种范式的主要区别在于它们所采用的接口：MP 依靠传统的发送/接收接口，而 CXL 通过提供更细粒度的远程 LOAD/STORE 指令集与 DSM 实现更紧密的一致性。然而，我们认为计算与内存关系的根本假设才是更关键的考量因素。

首先，消息传递范式倾向于采取紧密耦合的架构，每个节点仅能访问其本地内存。而支持 CXL 的 DSM 系统则自然倾向于解耦架构，将计算和内存资源分散到不同的资源池中[4]，这样做能够实现资源的更灵活、更高效利用。其次，就数据通信而言，消息传递通常涉及将数据有效负载从一个节点复制到另一个节点，这是一种按值传递（pass-by-value）的方法。另一方面 DSM 使用了引用传递的方法，只需要交换对于对象的引用使用了引用传递（pass-by-reference）方法。这有助于仅访问必要的数据部分，并实现就地更新，为一些特性的场景带来显著的性能提升。例如，我们开发了一个基于 CXL 的 RPC 系统POC，用于验证引用传递的优势。它避免了数据复制和网络栈的开销，因此吞吐量比传统的基于 RDMA 的 RPC 系统高出 4 倍以上。

最后，DSM 提供了全局内存空间的可访问性，这意味着所有数据和状态都是共享的。这一特性有利于工作负载的快速迁移。例如，在“share-nothing”架构中解决负载不均衡问题通常需要数据的大量重新分区，而在“share-everything”模式下，只需交换代表数据分区所有权的元数据即可。

总而言之，在那些需要高度灵活性的应用场景中，基于 CXL 的 DSM 表现出色。CXL 架构自然支持这种灵活性，它提供了动态且高效的方式来分配和访问远程内存资源，这对于需要能够快速、高效扩展的系统来说至关重要。

基于 CXL 的 DSM 面临的挑战

然而，过渡到基于 CXL 的 DSM 范式不仅仅只是享受硬件进步的红利。DSM 范式通过使用同一地址内存空间来维护共享状态，从而实现更快的数据传输和迁移，同时将计算与内存解耦以增强可扩展性。然而，考虑到并发访问的情况以及可能出现的部分故障（partial failure），管理这些共享状态会比传统的 share-nothing 架构更加复杂。

本质上，我们面临的挑战源于共享分布式对象和引用它们的客户端分别有单独的故障域。具有这种单独的故障域，能够允许客户端在执行任务期间自由加入、离开系统甚至宕机，因为它们创建、释放和交换对远程内存的引用。虽然这种灵活性是用户友好的，但它给内存管理带来了巨大的挑战。我们将其称为部分故障弹性 DSM (RDSM)，以将其与所有客户端同时失败的情况区分开来。我们认为，有效处理部分故障对于扩大 DSM 的使用至关重要。

为了应对这些挑战，我们在 SOSP 23 上的论文“Partial Failure Resilient Memory Management System for (CXL-based) Distributed Shared Memory”[5] 提出了一种采用引用计数来减少回收远程内存所涉及的手动工作量的方法。然而，标准引用计数系统对于系统故障而言鲁棒性并不强。我们将维护自动引用计数的过程分为两个不同的操作。当客户端想要创建引用时，第一步是增加引用计数。接下来，我们通过将引用的值赋为被引用空间的地址来链接该引用。而回收引用是一个类似的两步过程：递减引用计数，然后将引用设置为 NULL。虽然只有两个简单的步骤，但它们的顺序至关重要。如果这两个步骤之间发生系统崩溃，就会出现问题。

例如，如果我们增加引用计数但由于崩溃而未能设置引用，则可能会导致内存泄漏。一个简单的解决方案是使用锁来确保引用计数的修改是幂等的，并记录此更改以用于后续出现错误之后的恢复。然而这种方法仅在所有客户端同时失败的情况下才有效。在部分失败的情况下，客户端可能在获取锁后崩溃，这可能会导致我们方案进一步的复杂化。为了解决这个问题，我们改变了原始算法中使用锁的方式，转而使用了分布式矢量时钟来做非阻塞更新。这一调整使我们能够保持全局一致的时间表，而不需要锁机制。有关该方法的更多详细信息请参见论文。

未来方向：基于 CXL 的 DSM 商业化策略

除了探究基于 CXL 的部分故障容错 DSM 架构的技术细节，我们还发现这种范式与云计算的发展方向不谋而合；云计算本质上追求的是极致的弹性。云基础架构的演进带来了更细腻的计费模式，促使用户和提供方都能实现更高层次的资源使用效率。然而，由于传统应用程序固有的缺乏弹性，尤其是它们对内存状态的本地化处理，常常未能充分利用这些技术进步带来的潜在优势。突破这一局限，将是 CXL 研究领域面临的重要机会和挑战。

后记

受到 ACM SIGOPS（美国计算机协会操作系统兴趣组）邀请，本文英文版发表在该协会的博客上（https://www.sigops.org/2024/revisiting-distributed-memory-in-the-cxl-era/）。本文的相关工作 CXL-SHM 则发表在操作系统顶级会议 SOSP 23 上。

作者：阿里巴巴技术专家马腾 、清华大学助理教授章明星

引用

• [1] Donghyun Gouk, Sangwon Lee, Miryeong Kwon, and Myoungsoo Jung. 2022. Direct Access High-Performance Memory Disaggregation with DirectCXL. In 2022 USENIX Annual Technical Conference (USENIX ATC 22). 287–294.
• [2] LI, H., BERGER, D. S., HSU, L., ERNST, D., ZARDOSHTI, P., NOVAKOVIC, S., SHAH, M., RAJADNYA, S.,LEE, S., AGARWAL, I., ET AL. Pond: Cxl-based memory pooling systems for cloud platforms. In Proceedings of the 28th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, Volume 2 (2023), pp. 574–587.
• [3] 2022. Compute Express Link 3.0. https://www.computeexpresslink.org/_files/ugd/0c1418_a8713008916044ae9604405d10a7773b.pdf.
  [4] 2022. Compute Express Link CXL 3.0 is the Exciting Building Block for Disaggregation. https://www.servethehome.com/compute-expresslink-cxl-3-0-is-the-exciting-building-block-for-disaggregation/
• [5] ZHANG, M., MA, T., HUA, J., LIU, Z., CHEN, K., DING, N., DU, F., JIANG, J., MA, T., AND WU, Y. Partial failure resilient memory management system for (cxl-based) distributed shared memory. In Proceedings of the 29th Symposium on Operating Systems Principles (2023), pp. 658–674.

原文链接

本文为阿里云原创内容，未经允许不得转载。