LWN：CXL 如何管理以及分层！

关注了就能看到更多这么棒的文章哦～

CXL 1: Management and tiering

By Jonathan Corbet
May 13, 2022
LSFMM
DeepL assisted translation
https://lwn.net/Articles/894598/

Compute Express Link（CXL）是一项新出现的内存技术，显然是 Linux 内存管理开发者很关注的；在 2022 年 Linux 存储、文件系统、内存管理和 BPF 峰会（LSFMM）上，有五场会议专门讨论这个话题。5月 3 日的前三场会议涵盖了 CXL 情况下内存管理的各个方面。看起来 CXL 可能会带来一些受欢迎的功能，特别是对云服务提供商来说，但这将给内核开发带来一些麻烦。

CXL 的本质是一种将内存连接到 CPU 的新的方法。该内存不需要位于本地的内存总线上。也就是说很可能位于另一个完全不同的设备上。CXL 供应商设想中有 "memory appliances" （内存服务） 用来以灵活的方式向多个系统提供内存。对 CXL 的支持又引发了一些跟系统启动、内存热插拔、内存分层等相关的有趣问题。

A CXL memory interface for containers

第一场会议是由 Hongjian Fan 通过远程接入来主持的，其重点是如何使用 CXL 内存来支持容器（container）。他说，由于 CXL 是新技术，还没有现实设备可用，所以很难完全弄清楚这个问题。因此，大部分工作目前都是在概念层面进行的。Kubernetes 容器存储接口（container storage interface）提供了一种灵活的方式来为容器分配存储空间，他正在研究一个 "容器内存接口"（CMI, container memory interface），对 CXL memory 做同样的事情。

系统可以使用 CMI 来提供内存分层（memory tiering）等功能，并在 pooled-memory system 中管理资源。对于这一切是如何运作，Fan 设想了几种情况。一种情况是，容器可以访问系统可用的所有内存（当然是由 cgroup memory controller 来管理的）；在这种情况下，CXL 不会带来什么变化。相反，如果容器实现了 tiered memory，那么 CMI 将控制对不同内存类型的访问。还有一种 pooled-memory 场景，也就是内存位于其他的某个设备上。

Fan 提出了一系列问题，希望寻求答案。第一个问题是，是否有可能创建一个通用的 CMI 标准，在所有 CXL vendor 中都起作用。关于内存分层，他想知道是应该在容器内做，还是需要在 host 这边完成？关于如何管理 pooled-memory 服务器，也有一些开放性的问题。一位与会者在讨论开始时就问，是否可以用 cgroup 来管理所有这一切，来将不同类型的数据打包起来，就像它们是无 CPU 的 NUMA 结点一样来处理。Fan 回答说，这可能是一个最简单的开始方式，但他不确定 cgroup 是否有足够的灵活性。

Michal Hocko 说，cpusets 也许可以帮助进行管理，但它们没有提供方法来控制内存应该如何在节点间分配。Dave Hansen 说，人们希望能对内存分配进行控制；例如，供应商可以对访问较慢的内存收取较低的费用。这个问题现在就存在，人们试图用 numactl 工具来管理，但不太能胜任。他说这个工具可以阻止用户使用某些类型的内存，但要么是全同意，要么是全拒绝，不能提供供应商想要提供的更精细的服务质量（quality-of-service）控制。

Dan Williams 说，目前的工作一直集中在 DRAM 和较慢的内存之后。CXL 将带来更广泛的供应商以及不同速度、不同性能等级。虽然现在设计一个系统来处理两层内存的服务可能是有意义的，但开发者应该考虑未来可能会有五层。不过 Matthew Wilcox 认为企业供应商不太可能想要管理这么多层级。

Adam Manzanares 建议先明确定义好使用场景开始，也就是做两层。否则，他担心情况很快会失去控制。Wilcox 说，有一个由 CXL 存储器、DRAM 和持久性存储器（persistent memory）组成的三层场景，这是一个合理的案例。但 Hansen 警告说，会出现连接多组 CXL 层级设备上来，开发者还会很可能看到 "许多奇怪的 CXL 设备"。毕竟它是一个开放标准，供应商可以基于它来自由地做一些有趣的事情。

Fan 说，为了使管理能发挥作用，内核需要对每一层可用内存的相对性能要有一些了解。Hansen 回答说，在这个领域有很多标准工作。例如，ACPI 有一种方法可以来 enumerate 获取 NUMA 延迟，其他机制也在开发之中。例如，异构内存属性表（HMAT, Heterogeneous Memory Attribute Table）可以为每种类型的内存都提供带宽信息。同时，UEFI 已经定义了 Coherent Device Attribute Table（CDAT），其中就考虑到了 CXL 内存等类型。

Williams 说，Linux 过于依赖 NUMA distance 的概念来作为描述内存能力的一种方式。现在 firmware 提供了更好的内存信息，但是内存管理代码并没有利用上。可以有一个小步骤来将这些信息归结为单一 distance 值，这样至少可以利用一下了。不过 Manzanares 说，distance 对 persistent memory 是不适合的，因为这个概念无法表现出读写速度之间的不对称性。

Hansen 说，如果一个应用程序知道该去哪里查，那么现在就可以获取到相关的信息。更困难的问题是在内核中确定出这个内存放在哪里。不同的 workload 可能有不同的偏好，这取决于相应的访问模式；目前，应用程序必须弄清楚他们需要哪种内存，并设置一个适当的 NUMA 策略。但是，内核可以使用内存信息来做出更明智的决定。例如，将经常写入的 page 从 persistent memory 中移走。

关于应该在哪里来决定如何分层也有一些讨论。Williams 说，把逻辑放到内核中，对于那些不关心 NUMA 位置的应用程序来说就很方便了，这也是大多数的应用程序所期望的。但是他担心内核和用户空间之间可能会就分层（tiering）问题发生争执。Hansen 说，这些争斗现在可能会发生，但是如果用户空间已经设定了明确的 policy，内核的 NUMA 放置的相关逻辑就可以保持不去破坏它。这可能也足以满足未来的需要。

Williams 要求解释一下当前 NUMA API 中的缺陷。Fan 回答说，需要有一种方法来设置每个节点的内存限制；这就需要一个新的 cgroup 或 numactl 开关。Manzanares 建议在 QEMU 中加入更好的 tiered-memory 支持，这样这项工作就可以继续进行，但 Davidlohr Bueso 指出，这样不可能从中获得真实的性能数字。Manzanares 说，目前的关注点是解决接口问题，而不是优化性能。Hansen 说，把一些 persistent memory 放到系统中并把它当作另一个 tier，就可以做很多事情，这样一来 "如果你仔细看的话，就有点像 CXL 了"。这就可以提供一个来尝试接口的方式，并获得一些初步的性能数据。

Fan 感谢了大家为他提供了许多有价值的信息，会议到此结束。

Managing CXL memory

下一场会议由 Jon Trantham 主持，深入探讨了在试图管理 CXL 内存时出现的一些其他问题。他介绍了 CXL 是一种连接用来连接不能进入 DDR 内存总线的内存设备的方法。对制造商来说，把 DDR 接口放到设备上是很困难的，而且 DDR 对 persistent memory 的作用也不是那么好。但 CXL 内存的性能特征与普通 RAM 不一样，它的延迟和带宽就不一样，而且会随着设备的老化而改变。持久性、耐用性和可靠性也都可能会不一样。

有多种方法来报告 CXL 内存的特性和状态，首先是上面提到的 CDAT table。CDAT 很有用，因为它可以随着性能变化而进行更新。CXL 设备还可以产生一个 event record 数据流，比如用来告知需要维护了，或者性能下降了。CXL 2.0 实现了用来放在内存和计算机之间的 swtich 开关，允许内存完全位于另外一个设备之中。这就使得热拔插等行为变得可能了，但需要弄清楚如何将其传达给内核。

CXL 设备必须实现一些决策，关于给每个处理器分配多少内存；这可能涉及一个 "out-of-band fabric manager" 来控制这些 switch。内存可以以小到 64 字节的粒度来进行 interleave 访问，这对提高性能来说是很有价值的，但对错误恢复（error recovery）来说却比较困难；内存故障（memory failures）会导致地址空间中出现小的空洞。Wilcox 回答说，在这种情况下，通常的管理技术就是直接 crash。

在安全方面，有 host 和 device 之间共享的 access 和 encryption 密钥；这就带来了全套的密钥管理的问题。他说，这一切都需要大家的帮助才能完成。如何管理这所有一切呢？应该在内核中还是在用户空间中进行？

Williams 问，加密功能是否只是针对持久性内存（persistent memory）的。显而易见，CXL 可以为 DRAM 提供 link encryption，但并会不对静态数据进行加密。Hansen 说，内核永远不可能从 64 字节边界的错误中恢复，它只能在 page 级别进行内存处理。他建议看看现有的机制，问问是否真的需要什么新功能，也许所有这一切 CXL 的功能都并不是真需求。

Williams 说，CXL 可以让 baremetal （裸机）变成虚拟机；内存膨胀（memory ballooning）等技术也成为可能。因此，似乎应该使用相同的接口。Hocko 说，内存膨胀依赖于内存热插拔功能，这 "多少时候是可用的"，但要想缩小内存就很难了。要删除的内存只能是用来做 movable 数据分配的才行。这相当于回到了以前的 high-memory 类型的管理方式了，也就是安装上来的大部分的内存不能被内核使用。

Hansen 回答说，内核在清空要删除的内存区域方面做得很合理，但总有这样的情况，有几个 page 根本无法被清除掉。他说，如果有某种方法可以在内存消失后继续保留这些 page，那么一切就容易多了，整个机制也会更可靠。

会议结束时，Manzanares 建议开发者和供应商之间进行更多的协调。也许需要有定期的小范围电话会议来解决这些问题。有可能很快就会建立起这样的渠道。

Tiering

周二的最后一场 CXL 会议是由 Jongmin Gim 主持的，他想具体谈谈 tiering 的问题。他一开始介绍说，CXL 2.0 规范中的很多东西都在改变，包括增加了一些内存类型。tiering 会使系统能够最好地利用这些内存类型，将经常使用的 page 放在快速内存（fast memory）中，而使用较慢的内存来保存那些不经常需要的 page。

目前，tiering 的支持还没有放到 upstream 里，但开发人员正在进行这方面的工作。围绕着多个 tier 之间的 page 的提级以及降级，有各种问题需要解决。他说，降级很容易，如果没有足够的快速内存可用，就把一些 page 踢出去。不过，提级就比较困难了。目前的 patch（在 https://lwn.net/Articles/893024/ 这篇文章中描述）使用 NUMA-balancing scan 来试图确定较慢的内存中的哪些页面目前正在被使用。发现 hot page 时就可以被迁移到更快的内存中。有一个启发式方法就是要求在对一个 page 进行提级之前要进行两次访问，这有助于防止 page 在两种不同类型的内存之间来回频繁跳。

这里有一个可能的优化就是在一个独立的操作中把连续的多组 page 放到一起。有一些讨论是关于实施某种预测算法来改善 page 提级操作的，但这都是在比较高层进行的处理。

Manzanares 说，内核的 NUMA 平衡设计的时候，系统中的所有节点都是或多或少平等的，并且它是以 CPU 为中心的。他想知道 NUMA 平衡中的这些假设在 CXL 世界中是否仍然有效。Gorman 说，在目前的代码中，没有假设 numa 节点是相同 size 的。Hansen 说，NUMA 平衡现在被用来将数据从较慢的持久性内存节点移出来或者移进去，这些节点的 size 总是不一致的，目前看来还是可以正常工作的。

讨论围绕着 NUMA 平衡的一些细节在进行，并没有真正的结论。不过，在会议结束时，有两点是大家达成一致的：CXL 设备是高度多样化的，而 tiering 则是对它们进行管理的方法。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～