LWN: Top-tier memory management！

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

Top-tier memory management

May 28, 2021
This article was contributed by Marta Rybczyńska
DeepL assisted translation
https://lwn.net/Articles/857133/

现代的计算系统中可能有多种类型的 memory，它们的性能表现各不相同。最常见的例子就是 NUMA 架构中属于 local node（当前节点）的 memory 比其他 node 的 memory 的访问速度更快。最近，持久性内存（persistent memory）也开始得到部署，这种 memory 可以像 DRAM 一样可以逐字节寻址，但是它的空间更大，而且访问速度更慢（尤其是在写入时）。这种新的内存类型导致内核的内存分配更加复杂，促使人们寻找方法来更好地管理一个系统中的多种内存。

NUMA 架构中把内存划分为比较靠近当前 CPU 的内存以及距离较远的内存。这些较远的内存通常是连接到其他的 NUMA 节点的。这两种本地内存（local memory）和远程内存（remote memory）的访问性能是有差异的，因此，内核之前已经支持了 NUMA 拓扑结构。要想使 NUMA 性能最大化的话，内核需要让 memory page 尽量放在靠近会使用这些 page 的 CPU 的位置，但也允许在 NUMA 节点上进行虚拟内存分配从而能达到可预测的全局性能要求。内核文档(https://www.kernel.org/doc/html/latest/admin-guide/mm/numa_memory_policy.html)中介绍了 task 如何配置 NUMA 系统上的内存位置。

NUMA 机制能扩展用来管理持久性内存，但是它本来并不是为了这种情况设计的。今后可能会有更多类型的内存，比如高带宽内存（HBM，High Bandwidth Memory），也就是将 DRAM 芯片堆叠（stack）起来并提供更强大的内存总线（memory bus）。迟早有一天，会需要一种新的方法来管理这些差异巨大的 memory。

最近，内核开发者一直在讨论一个可能可以解决不同的 memory type 的问题的方法，也就是新增一个 memory tier （内存层级）的概念。这里提出的代码对 NUMA mode 进行了扩展，增加了将不经常使用的页面迁移到慢速内存、将常用页面迁移回快速内存等功能，并实现了控制该功能的机制。要想能支持多个 tier（层级）的内存管理子系统的改动会非常复杂，开发人员正在讨论三个相关的 patch set，每个 patch 都建立在之前的基础上。

Migrating from fast to slow memory

首先是 Dave Hansen 发布的 patch set。它改进了内存回收（memory reclaim）进程，其一般是在内存紧张时启动，用来将很少使用的 page 中的内容 push 出去。Hansen 说，在一个具备了持久性内存的系统中，这些 page 可以从 DRAM 迁移到较慢的 memory 中，后面如果再次需要这些数据了，也是仍然可以直接访问到的。汉森在 patch 的说明邮件中指出，这只是一个部分解决问题的方案，因为被迁移的 page 将被永远困在慢速内存区域中，没有回到更快的 DRAM 中去的机制。这个迁移出去的是一个可选项，用户可以通过 sysctl 的 vm.zone_reclaim_mode 或者说/proc/sys/vm/zone_reclaim_mode 中把 bitmask 设置为 8 从而启用这个功能。

这组 patch 初步收到了一些积极评价，包括来自 Michal Hocko 的 review，他认为这个功能在没有 memory tier 功能的传统 NUMA 系统中也会很有用。

…and back

接下来是 Huang Ying 提出的一组 patch，用来将经常使用的 page 从慢速内存迁移到快速内存。

在目前的内核中，对 NUMA 进行 balancing（平衡）操作是通过定期对进程的 page 页面进行 unmap 操作来实现的。当某次访问一个未被 map 的 page 而触发 page fault 时，这部分 migration 代码会决定相关的 page 是否应该被移到发生 page fault 的内存节点上。是否迁移取决于多种因素，包括这个访问发生的频率以及所访问的节点上的内存是否还有可用的（available）。

这个 patch set 利用了这些 page fault 来对哪些 page 属于常用 page 进行更准确地估算，它取代了当前的算法（当前算法认为那些最近访问过的页面都是常用 page）。新的估算方法会依据从 page unmmap 到发生 page fault 之间的时间差来判断 page 是否常用，并提供了一个 sysctl 开关来定义阈值：kernel.numa_balancing_hot_threshold_ms。所有 page fault 时间差低于阈值的 page 都被判定是常用 page。对于系统管理员来说可能很难决定这个阈值应该设置成什么值，所以这组 patch 中的最后一个就实现了自动调整的方法。为了实现这个自动调整，kernel 会根据用户设置的平衡速率限制（balancing rate limit） numa_balancing_rate_limit_mbps 来对迁移的 page 数量进行监控，通过增加或减少阈值来使 balancing rate 更接近该目标值。

Controlling memory tiers

最后，Tim Chen 提交了一组关于 memory tiers 的配置管理的 patch，其中 top-level tier（最高级别的层级）包含了最快的内存。这组 patch 还是基于 cgroup v1 的（Chen 也介绍说对 cgroup v2 的支持正在进行中），它会监控系统和每个 cgroup 中各自使用的 top-tier 内存的数量。它使用了 soft limit，用 kswapd 来把某个 cgroup 中超过 soft limit 限制的 page 迁移到较慢的 memory 类型上去。这里所说的 soft limit，是指如果 top-tier memory 很充足的话，cgroup 可以拥有超过此限制的 page 数量，但如果资源紧张的话则会被迅速削减从而满足这个 limit 值。

Chen 的 patch 中，cgroup 的 soft limit 被称为 toptier_soft_limit_in_bytes。这些代码还会跟踪统计 top-tier memory 的全局使用情况，如果空闲的内存已经少于当前 node 整体内存的 toptier_scale_factor/10000 的话，kswapd 就会开始对超过 soft limit 的那些 cgroup 进行内存回收。

Hocko 不喜欢这里使用的 soft limit 方式：

过去我们已经认识到，由于需要向后兼容导致现有方案有时候是无法 fix 的，因为不能改变现有的语义。所以我真的希望别使用 soft limit，避免出现某些真的利用了 soft limit 的使用场景。

Hocko 不喜欢 soft limit 的原因可能来自于之前那次尝试改变 interface（LWN 在 2013 年和 2014 年报道了这些讨论，https://lwn.net/Articles/592045/ ）。缺省的 soft limit 设置是 "unlimited"，这个没法修改，因为可能会导致破坏向后兼容。

在进一步的讨论中，Shakeel Butt 提出了一个使用场景，即让高优先级的任务获得更多 top-tier memory 访问优先，而低优先级的任务则要受到更严格的限制。Yang Shi 指出了一些初步工作进展，对于不同的任务划分快、慢内存（fast and slow memory），并得出结论认为这个解决方案在实践中很难使用起来，因为它需要对具体系统中的冷热内存（常用、以及不常用的内存数据）要有很深入的了解。开发者们讨论要对所使用的内存类型进行更精细的控制，但没有达成结论。

在讨论停止之前，Hocko 提出了一些想法，建议接口可以设计成这样：不同类型的内存被配置到独立的 NUMA 节点中，task 可以声明他们希望让哪些节点来提供它要使用的内存，也就是它的偏好。当内存不够用时，某些节点可以先于其他节点来进行内存回收。他还进一步指出，这应该是一个通用机制，而不是基于这些 CPU node 中的 persistent memory 的位置：

我并不是建议要做 per NUMA limits。[…] 我想说的是，我们不希望最后的接口像你的 patch 中的做法那样，会跟某种特定的硬件配置（比如要用 fast RAM 作为 top tier，PMEM 作为后备内存区域）紧密绑定起来。我们希望看到一个基于 NUMA 的通用抽象方案。

Next steps

在写这篇文章的时候，上述这些 patch 没有一个被合并，而且看起来近期也不会有。内存管理的改动都需要时间。而且在最终解决方案敲定之前，开发人员需要先对如何控制不同工作场景中快、慢内存使用的方式达成一致。top-tier 管理的这些 patch set 是专门用来讨论的素材，肯定不会以其目前的形式合入 mainline。我们可能会在未来几个月看到关于这个问题的更多讨论。

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

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

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