OutLine
- Pond 介绍（Pond 是什么）
- Pond 背景 & 内存池的引入
- Pond 系统设计（预测模型）
- Pond 硬件系统设计（EMC 相关）
- Pond 实验图片分析
- Pond 和 baseline 对比
- Pond 值得借鉴的方法论
介绍
- Pond 是第一个既能满足云服务性能要求（性能下降可控），又能提高 DRAM 的利用率 -> 降低了 TCO（总成本）的云内存池系统，它是由 CXL 接口实现，并且集成了机器学习的预测模型，能准确地给每一个虚拟机分配恰当的 DRAM 内存和 CXL 内存。
- 通过对云服务生产环境轨迹数据的分析，跨 8-16 个处理器插槽实现内存池化，即可获取该技术的绝大部分收益
- 构建机器学习模型，精准预测为虚拟机（VM）分配的本地内存与池化内存资源量，使虚拟机性能接近同非均匀内存访问（NUMA）节点的内存性能表现。基于 158 种工作负载的测试验证表明，Pond 可将 DRAM 成本降低 7%，且其性能仅比同 NUMA 节点的虚拟机资源分配方案低 1%-5%
背景
- 内存墙：算力增长速度超过内存，每个 Core 平均的内存量越来越少
- 内存成为服务器的费用大头：内存成本占服务器总成本的 50%（最近内存条的价格也在增长）
- 内存搁浅问题：根据 Azure 的生产环境分析，在 CPU 高负载的集群中，有 25% 的内存没有被使用；在已经分配给 VM 的内存中，有 50% 的虚拟机的 50% 内存属于 untouched 状态
内存池的引入
- 分配 VM 时通常会为 VM 分配 Core 和预留足量的内存，这种方式强耦合了计算资源和内存资源，缺乏了弹性和动态性
- 解决内存搁浅问题的有效手段之一是构建分离式内存：我们可以将每个 VM 预留一部分内存用来作为共有的内存系统，然后从共有的内存部分动态分配内存
- 下图 3 显示了当虚拟机把自己的 DRAM 分别以 10%, 30% 和 50% 分配给内存池时，随着 Pool Size[CPU Sockets] 的增大，需要总的 DRAM 量的减少。
- 随着 CXL 的出现，我们可以使用 CXL 内存拓展器作为一个统一的新的 NUMA 节点，作为一个分离式共享内存池（pooling memory via memory disaggregation）
- 为什么要使用内存池代替分离式内存？
- 将内存资源和计算资源的耦合中解绑出来，将内存变成了“可治理的系统资源”
- 现在 CXL 的延迟（latency）虽然依旧比跨 NUMA 通信高，但是池化对于资源的延迟的可预测性更好，同时多 NUMA 共享内存存在严重的污染 NUMA 亲和性，需要热迁移等问题
Pond 系统设计
约定：UM 表 Untouched Memory，ML 表 Machine Learning，Pool Memory 等同 CXL 内存
概括
- Pond 是为了预测 VM 分配的 Pool Memory / DRAM 比例所设计的，这个过程发生在 VM 分配之前，所以整个流程大致如下：（里面存在两套 ML 模型，我姑且称为 UM 预测模型和性能下降判断模型）
- 一个客户的 VM request 由 Pond 接收后，Pond 根据历史 Workload 用性能下降模型判断是否属于内存敏感应用，如果敏感，则调用第二套 UM 预测模型推测该 VM 内存未使用率大致为多少
- 如果不敏感，则全部分配 Pool Memory；如果敏感，则部分分配：假设申请内存数为 100GB，我们发现它的内存未使用比例预测为 30%，我们将会为其分配 70G DRAM 和 30G 的 Pool memory
- 分配好后，使用 Monitor 实时检测其性能下降以及同时采集用于训练的数据（指 UM），Monitor 通过性能下降模型判断 VM 性能下降则进行热迁移
- 每 24h 用收集到的数据重新训练机器学习模型（论文中用的随机森林）
判断性能下降模型
- 判断性能下降是一件难事，如果只使用 PMU 指标，很难单一表示性能的变化；如果使用成套的系统，不可避免的带来额外开销。
- Pond 使用 PMU 作为 feature 训练了一个性能下降判断模型，我觉得一个值得我借鉴的点在于它的训练数据：找了 100+ 个已知是否应用敏感的 workload 作为数据 Label，然后再收集过程 PMU 作为 feature 训练该系统
- 这套 ML 系统用于两处：1. 在 VM 分配前根据历史 workload 来判断应用类型 2. 在 VM 启动后，作为 QoS Monitor 根据过程 PMU 检测应用是否性能下降
预测 UM 模型
- 根据客户的 Region，OS，申请 VM 类型，Workload 历史记录推测具体的 UM 比例，根据 UM 比例分配 Pool Memory
- 感觉客户的 Region，OS 类型，VM 类型等信息不足以判断 UM 定量的预测，Pond 论文说明这件事情反直觉地可以事实论证可行
- UM 是如何测量的：Pond 使用 Access Bit 来判断完全没有使用过的内存页容量（Access bit 是系统原生的页的参数，开销极小）
硬件系统解读
EMC（external memory controller）
- EMC 作为一个多头的硬件接给不同的 Host 使用，作为不同 Host 共享的一个外部设备使用；所有 CPU socket 通过 CXL 接口访问 EMC 嵌入在上面的额外内存
- EMC 将里面的内存全部切片，大小为 1G，每一片一次只能分配给一个 Host 使用（现在 CXL 内存拓展器多也是这种结构，通过分片来规避了多个 Host 之间的内存一致性的维护，现在只需要维护 Ownership）
- 随着更多 Socket 共享 EMC，我们需要更多的 Switch 和更复杂的线路，相对应的延迟就会更高；事实证明，在 8-16 socket 下，能获得一个较好的内存共享利用率升高以及可以接受的延迟增长
PM（Pool Manager）
- 分片管理器是 PM（Pool Manager）的一个功能，而 PM 是和 EMC 嵌在一起的一个结构
- PM 和 EMC 和 CPU 之间都通过一个 lower-power bus 连接
- PM 会发送一个 Add_Capability 告诉 Host 的 Driver 来给其分配 CXL 内存片 slice
Slice 要避免内部碎片
- 在池化内存架构中，内存是跨主机共享的。如果某台主机想要将 1GB 的内存“离线”（offline）并还给内存池，以便分配给另一台主机，这 1GB 的连续地址空间必须完全为空。
- 但是，主机代理（Host Agent）和 Driver 有时候会借用这 1G 的空间存放元数据等信息，导致 VM 不能顺利归还这 1G 空间，导致整块空间被 pin 住
- 所以 Pond 将 Memory Pool 设置成特殊内存只能被 hypervisor 使用，而 Host Agent 和 Driver 都会被放到 Host-Momory 里面
Pool 内存不 interleaving
- 本地的内存 DRAM 为了访问速度，可能数据分布在不同的内存条上进行低地址交叉放置数据
- CXL 内存为了热插拔以及故障不影响整体性能，不采用 interleaving
部分实验结果分析
zNUMA VMs on Production Model
- 在一个小规模的生产集群下，将 zNUMA 开放，看各个 workload 的变化和负载
- Pond 秉行的是不自动调整冷热页面策略，只是单纯分配合适的比例给 VM（通常只有超过了 DRAM 容量，才会自动使用 Pool Memory）
- 在预测正确对的情况下，我们可以看到进入 zNUMA 的比例十分之小
Slowdown Under different Pool Allocations
- 该实验说明在正确预测 UM 下，性能不会出现明显下降以及各个应用的 UM 比例不同
- 在 Lab 的环境下，测试了 100+ 的 workload 测试在不同 Overprediction 以及 Correct Prediction，All DRAM 下的性能变化
- 第一个结论：在正确预测 UM 时，性能和 Local Memory 相差不大
- 第二个结论：在不同的 Pool Memory 下，会出现明显的 Slowdown，但是我们也能看到不同应用对于内存延迟敏感程度的不同，不同的应用应该使用不同比例的 UM（这个过程完全是由机器学习自动拟合）
预测精准性
- 该实验说明了为什么我们要使用训练一个性能下降模型，而不是直接使用比如说 Memory Bound / DRAM Bound 参数
- Memory-Bound：指和 L3 进行了交互的测试方法，DRAM 指和内存频繁交互的测试方法
- 通过放宽对于 insensitive 的标准来增加横轴，来判断误判率大小，可以看到随机森林明显的误判率偏低
UM 对比 Fixed Amount
- 该实验证明了为什么我们要使用 UM 预测模型而不是固定比例的从每一个 VM 去回收内存
- 这个图片的 AUM 指的是我们希望从 Pond 系统中每个 VM 中回收的内存比例
- 随着我们的越发贪婪去回收尽可能多的 DRAM，GBM 的过度预测比例小于 baseline（直接固定比例认为是多少）
- 目的：我觉得是为了证明 GBM“动态性”更好，和直接判断所需要的内存量而言，使用了动态选择池化内存，显然会拥有更好的精准性
UM 预测模型和生产环境真实值互相论证
- 环境：生产环境下的出来的平均内存搁浅在 25 % 左右，然后 Pond 的 OverPrediction 概率在 5% 左右
- 和上一个 Figure 18 相比较，得到的 OverPrediction 几乎相同，证明了模拟器上的预测 GBM 是真实且有效的
不同 CPU socket 下 Pond 性能变化
- 在性能下降容忍度为 5% 以及机器学习准确率 98% 这个限制下，测试了不同 CPU socket 时的一个内存节省情况
- 结论 1: 说明比起固定 15% 的 strawman 策略，显然使用 pond 节省的内存更加多
- 结论 2: 并且在不同的 CPU socket 下都能有一个比较好的效能，证明了 Pond 的实用性
baseline 对比
硬件级资源解耦 (Hardware-level disaggregation)
- 代表项目：ThymesisFlow, Clio (基于 FPGA 和专用协议)。
- 核心逻辑：通过自定义硬件（如 FPGA）和专用总线（OpenCAPI）在物理层实现内存池化。
- 缺点：硬件级方案依赖非通用（non-commodity）硬件，难以大规模部署。
虚拟机监控器/操作系统级解耦 (Hypervisor/OS level)
- 核心逻辑：利用操作系统的“缺页中断”（Page Fault）和访问监控，动态地把热数据留在本地，冷数据放到远程。
- 与 Pond 的区别：
- 性能开销：OS 级的处理会引入显著的延迟（Overhead）和抖动（Jitter）。
- 兼容性：这类方案与虚拟化加速技术（如 DDA/直通技术）不兼容。Pond 通过 ML 预测避开了这种频繁的中断处理。
运行环境/应用级解耦 (Runtime/application level)
- 代表项目：提供专门的 API 供开发者调用远程内存。
- 核心逻辑：开发者显式地告诉系统哪些数据存池子里，哪些存本地。
- 与 Pond 的区别：
- 开发负担：虽然有效，但需要开发者重写代码，对旧应用（Legacy apps）极其不友好。Pond 则是在平台层解决问题，应用无感知。
内存分层技术 (Memory tiering)
- 代表项目：Google 的热/冷页面检测、Nimble。
- 核心逻辑：在现有的分层内存（如本地 DRAM + 慢速内存）中，优化如何迁移页面、如何压缩数据。
- 与 Pond 的区别：
- 维度不同：分层技术关注“如何搬运数据”，而 Pond 关注“如何预测并分配池化内存”。
- 关系：Pond 与这些工作是正交（Orthogonal）的，意味着它们可以同时使用，互不冲突。
5. 其他领域
- ML for Systems：Pond 的独特之处在于将 ML 用于预测“用户不会用到的内存”（untouched memory），从而敢于在不降低服务质量（QoS）的情况下进行超售。
- NUMA 优化：
- 传统 NUMA：依赖缓存一致性（Cache Coherence），这在跨机池化中很难实现且开销极大。
- Pond 的突破：Pond 采用了“所有权”机制，避开了复杂的缓存一致性问题。
- zNUMA：针对 Pond 这种“只有内存、没有 CPU 核心”的零核节点（zero-core node），重新思考了传统的 NUMA 优化策略。
- 随着 CXL 3.0 支持了缓存一致性，但是 Pond 利用切分的思想合理规避了缓存性问题
Pond 中的方法论
- 在系统引入了机器学习预测：通过机器学习预测了 UM 大小以及判断性能是否下降，通过机器学习归纳了原有自带的繁多的参数
- 用了类似侧信道的方式去避开了云服务器中的“黑盒”问题：在云计算中应该不太能直接去扫描用户的页和抓取敏感信息用于预测，但是 Pond 中用类似“测信道”的数据（CustomID，OS type）等外围数据也能很好地预测整个“黑盒”的 UM
- 双向反馈控制：一个好的系统应该有良好的反馈能力以及自动迭代能力，Pond 用模型预测性能，以及再使用新的数据去完善模型；以及当预测失败后，有一套完整的纠错系统重新调度
- 系统问题建模：Pond 为了衡量应用性能下降，引入了 PDM 等指标；并且在实验中多次和生产数据对比，以及通过放宽标准来获得更多样的数据，用于说明实验的通用性以及补充实验的单一性