论文信息

• 文章来自ACM Transactions on Architecture and Code Optimization, (ATCO), 2022
• FlexHM: A Practical System for Heterogeneous Memory with Flexible and Efficient Performance Optimizations

所有作者及单位

• BO PENG, JIANGUO YAO, HAIBING GUAN. 上海交通大学。
• YAOZU DONG, FENGGUANG WU. Intel Asia-Pacific Research and Development Ltd. (好像成都的数据中心就是做云服务相关的，听说工资不太高)

Abstract摘要

随着云计算的快速发展，众多的云服务、容器、虚拟机给现代数据中心带来了对高性能内存资源的巨大需求，异构内存，特别是新发布的Optane内存，为云中的DRAM提供了合适的替代方案。具有容量更大、采购成本更低、性能良好等优点，但云服务在使用混合DRAM和Optane内存时，实施起来非常不便，性能下降严重。优化所有虚拟机、容器和原生应用程序的内存访问性能。我们在 Linux 中展示了 FlexHM 的开源原型，其中有几个主要贡献。首先，FlexHM 提出了一种新颖的两级 NUMA 设计，将 DRAM 和 Optane 内存作为透明主内存进行管理。（这也没啥新意啊？）其次，FlexHM提供灵活高效的内存管理，通过定制的管理策略，帮助优化内存访问性能或节省差异化云服务的内存资源采购成本。最后，评估表明，FlexHM上使用50% Optane慢速内存的云工作负载使用全 DRAM 时可实现高达 93% 的性能，当工作负载使用相同比例的 DRAM 和 Optane 内存时，FlexHM 比之前的异构内存系统解决方案提供高达 5.8 倍的提升。

1 Introduction简介

内存是云基础设施中对性能最关键的资源之一，关系到众多内存密集型原生服务、容器和虚拟机 (VM) 的服务质量 (QoS, Quality of Service)。云服务提供商 (CSP, cloud service providers) 通常会持续超额订阅内存资源并增加每台云服务器上内存密集型云工作负载的密度以获得更高的利润。假设云服务的内存资源需求超过了一台云服务器的 DRAM 容量。在这种情况下，云服务提供商（CSP）只能转向分布式内存系统，而分布式系统与大规模本地内存系统相比，严重降低了内存资源的可扩展性和利用率[35]。随着Intel Optane DC内存（本文简称为Optane 内存）[19]，慢速主内存（SMM）可以提供可靠的主内存替代品，与 DRAM 结合形成云服务器的异构主内存（HMM）系统。Optane 内存是非易失性内存的一种实现，它包括字节寻址功能，以其容量大、单位容量购买成本低的优势丰富了内存层次结构。目前，Optane最大为512GB per blade，而商用最大DRAM为128GB. Optane每 GB 价格大约是 DRAM 的 1/2-1/3 [6,16]. 但如果用作主存，Optane 与 DRAM 的性能差距不可忽视；例如，Optane 的峰值读取带宽是 DRAM 的 1/3，峰值写入带宽是 DRAM 的 1/6 [20]。

考虑到异构内存的性能和价格，异构主存（HMM）系统设计最关心的问题是系统如何优化HMM资源利用率，以更实惠的内存资源成本达到良好的业务性能。 在物理服务器（硬件）中构建和运行的云原生应用程序、容器和虚拟机对HMM系统提出了几个基本要求。例如，
-（1）他们更倾向于使用透明异构内存，而不是修改源代码并使用一些库或工具（如针对 Optane 的 PMDK [41]）调整编程模型，因为 PMDK 需要在 Optane 上进行繁重的编程和测试工作，以优化内存性能，而且它限制了框架移植到未来更多慢速内存设备（而不是 Optane）的便利性和灵活性。
-（2）在使用 HMM 时，它们的各种内存使用目的和不同的内存访问模式，以及它们对内存容量和整体吞吐量及延迟性能的多级 QoS 或服务水平协议 (SLA, Service Levels of Agreement)，都大大增加了管理难度，并最终影响了它们的整体内存性能。
-（3）在长时间运行过程中，它们通常会出现内存使用数据分布不平衡的情况，因此它们支付资源的意愿也不尽相同。例如，企业服务或虚拟机的大部分内存访问出现在每天的少数时间里[12]，而个人客户机则在其生命周期的大部分时间里空闲运行。

内存管理对于操作系统设计中的云内存性能保证和优化具有重要意义，特别是对于异构内存云系统而言，虚拟内存管理[7]、内存虚拟化[58]和非均匀内存访问（NUMA）[28]是基本且通用的操作系统内存管理技术。之前的许多工作通过使用 DRAM 模拟的非易失性内存 [1,4,10,25,30,33,38,55] 或内存控制器来研究现代系统的高效 HMM 管理解决方案模拟器[5,17,32,40,42,46,52]。然而，随着Optane内存的发布，最近的研究[34,49,57]已经证明，以前基于仿真的解决方案无法在实际应用中有效执行Optane 硬件以及那些模拟的内存设备因此，构建一个实用的系统来支持和管理真实的 DRAM 和 SMM 设备（例如 Optane）并优化本机内存工作负载、容器和来宾机器的性能和利用率引起了学术领域和操作系统开发者社区人们的关注。

在本文中，我们提出了 FlexHM，一种实用的异构主内存系统，具有灵活的 HMM 管理机制，因此云应用程序、容器和虚拟机可以透明地使用 HMM 并采用定制的管理策略来实现性能和价格高效的优化。FlexHM 构建了两个层NUMA（Distance and Heterogeneity Peer）在主流操作系统传统一层NUMA的基础上提供透明的HMM资源和内存虚拟化支持。然后FlexHM基于操作系统内核空间的内存性能监控与操作系统用户空间的使用分析和优化之间的周期性交互，对HMM进行管理。具体而言，我们研究了 FlexHM 的激进和保守管理策略，并证明 FlexHM 可以灵活高效地处理来自不同云工作负载的差异化 HMM 使用管理和性能优化需求。最后，我们通过微基准测试和应用程序基准测试（内存数据库和图计算基准测试）展示了 FlexHM 在综合内存密集型工作负载下的评估结果。例如，
-（1）使用 DRAM 和 Optane 慢速固定比例的微基准测试内存 (SMM) 的性能可达到 Thermostat 的 5.8 倍 [1]；
-（2） 使用 HMM (DRAM: Optane = 1:1) 的微基准测试可实现比全部使用 DRAM 的基准性能高达 93% 的性能；🤨😮
-（3） PageRank 应用程序基准测试可以使用较低百分比的 DRAM 资源（例如 DRAM:Optane = 1:3）来达到 5.7×性能提升与最先进的解决方案相比（使用 DRAM: Optane = 1:1），并节省 50% 昂贵的 DRAM 资源。😲

综上所述，本文做出以下贡献：

• 我们提出了 FlexHM，这是一个实用的开源系统，可在云中实现灵活且内存高效的性能和利用率优化，所有来宾、容器和原生应用程序都可以透明且高效地使用异构主内存。

• 我们在 Linux 中实现了 FlexHM 原型，用于管理透明异构主内存，包括 DRAM 和真正的 NVM 硬件 Optane 内存，并为基本 HMM 管理添加必要的内核模块，开源。

• 我们在FlexHM上设计了灵活高效的HMM管理，可以灵活采用定制的HMM管理策略，高效处理差异化的HMM使用需求，并开源，供社区进一步开发更多HMM 管理策略。

• 我们进行了全面的评估，以证明 FlexHM 系统可以为本机或来宾内存密集型工作负载提供高效、灵活的 HMM 管理。

• 我们讨论了FlexHM选择激进或保守管理策略时的管理效率，以及FlexHM与Optane两级内存模式等硬件缓存的优缺点。

本文接下来的内容安排如下： 第 2 节介绍了 FlexHM 的背景和动机。第 3 节介绍 FlexHM 系统的总体设计，第 4 节介绍用于 HMM 的双层 NUMA，第 5 节介绍灵活高效的 HMM 管理和性能优化。第 6 节介绍 Linux 原型的实现细节。第 7 节展示评估结果。第 8 节讨论了 FlexHM 的开销以及使用 DRAM 作为缓存的 HMM 系统之间的利弊。本文在第 9 节中结束。

2 BACKGROUND AND MOTIVATION

2.1 Heterogeneous Main Memory

Intel Optane DC持久内存（也称为Optane NVDIMM，本文简称为Optane内存）[19]是一种高性能商用NVM设备，Optane内存采用3D XPoint技术，内存颗粒密度更大，可以提供比 DRAM 更大容量、更经济实惠的主存资源。先前的研究[20, 56]表明，与 DRAM 相比，Optane 显示出相似的空闲延迟，但随机顺序加载延迟约为 DRAM 的 5 倍。我们还利用英特尔内存延迟检查器[51]进行了实验，并在图 1 中展示了测得的顺序和随机读写性能结果。从结果中我们可以发现，Optane 内存的随机读写性能比 DRAM 的顺序读写性能有更大的差距，而 Optane 甚至是最先进的慢速主存储器设备。因此，我们可以很明显地推断出，在操作系统中使用非易失性内存来取代易失性内存并重建当前的计算架构仍然是不现实和不可接受的。

Optane内存可以大幅提升一台云服务器的本地内存容量，提高服务、容器、虚拟机的密度，我们可以设想Optane以及未来的一些SMM设备可以与DRAM共存，作为云系统的异构主内存。目前Optane主要有两种使用模式，分别是APP Direct（AD）模式和内存（MM）模式，在AD模式下，操作系统最初将Optane内存设备视为字节可寻址但持久化的设备（不像主存，而是类似于闪存和磁盘）。在MM模式下，Optane内存使用来自相同内存通道的DRAM来构建包容性硬件缓存模型[21]，操作系统可以像易失性一样直接使用Optane. 因此，MM模式是现代系统的初步异构主存硬件解决方案，它可以通过固定的缓存替换算法（例如直接映射或LRU）从SMM加载和刷新DRAM缓存线。硬件解决方案存在三个主要缺点：（1）随着SMM容量的不断增长，硬件缓存实现将更加复杂和不切实际[32, 42]。（2）使用DRAM作为包容性硬件缓存会牺牲整个系统的总内存容量例如，当一台双路服务器配备 12 64 G DRAM blades和 12 512 GB Optane blades时，将浪费超过 10% 的总内存容量。 （3）硬件缓存只能采用刚性缓存替换策略（例如直接映射，伪LRU），在解决不同的云工作负载场景时不灵活。

这里其实就说硬件缓存实现复杂、内存浪费多、缓存策略不灵活

2.2 Heterogeneous Memory Management

异构主存资源的内存管理长期以来一直是研究热点[1,13,14,23,24,30,31,38,43,44,50,53,54,55]，我们表 1 总结了一些重要的研究工作。具体来说，Thermostat [1] 是一个典型的系统，它构建了一个应用程序透明的大页面感知机制，将具有在线页面热度分类的页面放置在 QEMU 的虚拟 NUMA 上。 SMM具有页面热度，但解决方案受到虚拟机的限制，无法满足原生云进程和容器的要求，而且这些相关工作的局限性在于它们通常使用DRAM来模拟慢速的NVM或使用内存模拟器来构建模拟异构内存环境，因此这些工作没有充分考虑真实 NVM 硬件的行为和性能来提供有效的优化。

具体来说，我们对这些先前的工作在实际 HMM 硬件上的表现进行了初步评估，我们选择来自 Github [37] 的 Thermostat 开源实现，构建系统，并使用 QEMU 的虚拟 NUMA 来运行 32- VCPU虚拟机，可以管理真实的DRAM和Optane内存作为其HMM资源。我们在这个VM中运行32线程Sysbench随机读写微基准测试，并比较Thermostat、MM模式（其中服务器的DRAM容量为其总Optane容量的1/4），并且是全DRAM基线。我们在图2中展示了内存访问吞吐量性能结果。从实验数据中我们可以发现，当我们让客户机使用 25% 的 DRAM 和 75% 的 Optane 内存作为其内存资源时（使用与 MM 模式环境相同的容量资源），与全部使用 DRAM 相比，客户机只能分别提供 18% 的随机读取性能和仅 3.1% 的随机写入性能。与使用 MM 模式为该虚拟机提供异构内存相比，Thermostat 的性能结果也要差得多。

我们进一步分析了Thermostat无法像在DRAM模拟的慢速内存上那样在真正的异构主硬件内存上高效工作的原因，根据参考文献[1]中的实现和评估环境，Thermostat的设计基于一个重要假设：异构内存性能，即慢速内存的延迟为约1𝜇. 但吞吐量并不比快速 DRAM 内存低。然而，尽管 Optane 内存是最先进的慢速内存硬件之一，并且它在延迟性能方面可以比假设更好地工作，但 Optane 和 DRAM 之间存在非常显着的吞吐量性能差距，特别是随机读写性能，由于Thermostat的性能优化是基于其系统内核中将热数据迁移到快内存、将冷数据迁移到慢内存，因此会在DRAM和Optane内存之间产生非常大的内存页面移动需求，因此当Thermostat使用非常激进的策略来进行异构内存页面的热度收集和迁移时，Optane的吞吐量性能可能会成为瓶颈，并且可能会比DRAM和Optane内存之间产生更多的内存访问和迁移开销。Thermostat可以对一些随机读写系统内存吞吐量较低的应用程序基准进行高效优化，不会给系统内核带来严重的热度收集和迁移开销，但它不能灵活地改变策略当密集型工作负载占用Optane内存峰值带宽时，在性能提升和开销之间取得更好的平衡。

因此，我们的目标是设计和实现FlexHM，为云计算提供灵活高效的HMM管理和性能优化。我们推断FlexHM必须具备以下功能，以处理来自原生服务、容器、以及云系统的虚拟机：

• 1）支持透明 HMM 使用和完全 HMM 虚拟化： 我们的目标是为所有原生云工作负载、容器和客户机提供灵活的透明 HMM 容量资源，而无需对其源代码进行任何修改。
• 2）使用固定HMM比率优化工作负载的性能：我们的目标是为具有固定HMM比率的工作负载提供运行时内存管理，以动态地将热数据从其SMM区域移动到DRAM区域并交换冷数据进入SMM区以达到更优化的内存访问性能和资源利用率。
• 3）优化 HMM 利用率，以达到更实惠的价格和可接受的性能下降：我们的目标是通过轻微且可接受的性能牺牲来节省 HMM 工作负载的内存购买成本，但满足其 QoS。我们可能会稍微减少 DRAM 百分比，增加SMM（Optane NVM）百分比，动态挑选冷数据并将其交换到SMM中。

  这感觉也没说啥，都是这样想的啊不光云服务

3 FLEXHM OVERVIEW

我们设计了FlexHM，一个实用的系统来管理异构主内存，具有高效灵活的运行时内存管理机制，以提供透明和快速的DRAM和其他SMM（例如Optane内存）并优化利用率。FlexHM架构的概述如图所示3，我们介绍了从硬件配置到系统内核以及用户和内核级协作的HMM管理的重要设计。

FlexHM硬件配置：FlexHM是一个建立在真实异构内存环境上的实用系统，例如使用DRAM作为快速主内存，使用Optane内存作为慢速主内存。与Optane的内存模式不同（Optane使用所有DRAM作为其硬件缓存），FlexHM系统使用的Optane资源在服务器BIOS中配置为APP Direct模式，因此FlexHM不会浪费DRAM容量，并且FlexHM内核可以将所有DRAM和Optane容量管理为所有进程的可用内存。这种配置有助于提高云服务器所有昂贵内存资源的更多效益。

FlexHM内核：我们基于Linux设计并实现了FlexHM内核功能，首先，FlexHM内核实现了异构内存硬件（例如DRAM和Optane）的透明资源管理，因为Optane本来就是作为一种更快的存储设备来使用的在配置APP Direct模式时，我们更新了Linux内核中原有的内存管理功能，将Optane作为缓慢但应用程序透明的内存资源进行管理，保持内核干净简洁，提高HMM管理和性能优化的效率，我们设计了一种用户和内核级协同的HMM管理机制来提高管理灵活性和效率，FlexHM内核为用户级管理器提供了基础支持，具体来说，我们引入了“kvm-ept-idle”模块用于将裸机原生服务和访客机的内存访问模式检查到FlexHM内核中。该模块可以提供可靠的内存使用信息，但不会直接触发任何系统进程的任何内存管理操作。FlexHM可以继承所有基本内存目前Linux系统的管理模块，我们只在FlexHM内核中引入少量内存页面管理策略来优化每个进程的异构内存分配性能。

FlexHM用户级管理器：我们在FlexHM的用户空间进一步设计了一个名为Memory-optimizer的HMM资源管理器，该管理器可以确定每个系统进程的快慢内存利用率之间的任意比例，并提供性能优化和利用率管理。可以针对不同的云应用、容器或Guest采取不同的定制管理策略，以满足其对HMM资源的不同需求或优化HMM资源利用率，具体可以利用来自内核的内存引用信息，分析工作负载的内存模式并触发异构内存之间的内存移动。如果工作负载希望在固定的 HMM 比率上优化性能，那么管理器可以动态地将其内存中的热数据选择到 DRAM 中，并将冷数据交换到 SMM 中。如果工作负载希望使用更多的 SMM 资源为了节省成本，它可以分析内存访问模式并提高其 SMM 使用百分比，而不会丢失 QoS。

（写到这里我终于知道作者干了什么事了，不过这些策略不是云相关的也可以用吧，好像没有太多云相关的应用特点被加入到作者的设计当中。）

4 TRANSPARENT HETEROGENEOUS MEMORY IN FLEXHM

在 FlexHM 系统中，Optane 内存在服务器 BIOS 中配置为 APP Direct 模式。但是，当操作系统在 Optane 上构建文件系统时，采用 APP Direct 模式的 Optane 不是主内存，而是最初用作比 NVMe SSD 更快的存储设备。因此，我们必须为操作系统的内存管理功能添加必要的支持，以将DRAM和SMM（如Optane）作为透明主内存进行管理。

考虑到非均匀内存访问（NUMA）可以有效地管理来自每个服务器不同硬件插槽的内存，我们在FlexHM中设计了两层NUMA，将所有HMM资源作为应用程序透明的异构内存进行管理。（让我来看看他和传统使用方法到底有啥区别……）两层NUMA是一种扩展主流操作系统中传统 NUMA 的特点，传统 NUMA 是一层 NUMA，因为它只考虑 CPU 访问距离，与本地或远程访问延迟有关；也就是说，传统 NUMA 只有一个特性讲述硬件socket的信息，并且不能准确描述考虑到内存异构性的内存引用差异，因此，为了管理内存异构性，我们引入了一个名为 “NUMA peer”的概念，作为第一层 NUMA 访问距离特性之外的第二层 NUMA 特性。因此，如果只有 Optane NVDIMM，操作系统可以将来自同一硬件插槽内存控制器的所有异构内存设备分离成一个 DRAM 对等节点和一个 SMM 对等节点；如果未来服务器上安装了多个 SMM 硬件，则可以分离成多个不同的 SMM 对等节点。（就是再给NUMA节点加了一个属性，MC是在热插拔时加上去的，这个不知道会用什么手段去定义？）距离和对等功能共同构成了 FlexHM 中的双层 NUMA，一个 FlexHM 系统可以拥有插槽数*内存硬件数的 NUMA 节点。例如，我们在图 4 中演示了双插槽服务器中的双层 NUMA 如何管理 DRAM 和 Optane。如果未来出现其他字节可寻址的慢速主存储器设备，那么双层 NUMA 设计也能轻松管理 DRAM、Optane 和其他 SMM 等更复杂的内存异构。

由于我们的FlexHM将所有DRAM和Optane作为两层NUMA的不同NUMA对等节点内的透明内存资源进行管理，因此我们引入了两个新概念：页面管理的升级和降级。具体来说，NUMA对等节点可以有升级和降级目标在FlexHM两层NUMA中，例如，内存页面可以从DRAM对等节点降级到SMM（Optane内存）对等节点，最后被回收到交换区域，反之亦然。如果我们有超过一个SMM，那么降级可以从DRAM开始到较快的SMM节点，然后到较慢的SMM节点，以此类推，升级反之亦然。升级/降级是FlexHM内存页面管理的基础，它给出了内核或用户级进程在不同 NUMA 对等节点之间移动内存页面的通用接口。

（审稿人会接受这是新概念吗？啊哈？可能好像以前的工作也没有明说咱们要把所有慢速的都归为第二层，那么你后续的设计最好让我们能看出来，是有针对各种慢速内存构成的第二层的特有的策略。因为如果慢速层，你的设计只有一种和上文NUMA peer的功能描述对不上，那不就相当于传统分层）而且，谁说SMM都可以线性得出一个排序。总之这种给NUMA第二个特点定义的，笔者有想过，但是什么时候去定义，用什么方式定义，一直没有觉得比较合适的方法。再加上现在已知数据的混合内存的设备也就那几种。

FlexHM 中的双层 NUMA 可以管理异构主内存的所有容量，并为所有系统进程提供透明的内存资源。此外，FlexHM 支持完整的 HMM 虚拟化，与使用硬件辅助虚拟化支持（如扩展页表 (EPT)）没有冲突。因此，从 CSP 的角度来看，每台运行 FlexHM 系统的服务器都可以提高云应用程序、容器和使用异构主内存的虚拟机的部署密度，而 CSP 也可以因为更好的内存资源可扩展性而提高利润。从云用户的角度来看，FlexHM 可以为他们提供极大的便利，让他们无需修改任何源代码就能使用更实惠的异构内存。此外，FlexHM 还可以通过使用一定比例的慢速内存来替代快速 DRAM，为他们的工作负载提供更实惠的内存资源选择。

看到这里好像也没有介绍清楚NUMA peer的实现细节，后面说不定会写。笔者猜测在NUMA结构体加了一个属性，并且可以人为定义这个属性，整个物理地址仍然是平面且顺序的。

5 FLEXIBLE AND EFFICIENT HMM MANAGEMENT

FlexHM现在可以支持透明的HMM使用以及基于两级NUMA设计的全HMM虚拟化，但是与使用所有快速内存（例如DRAM）相比，使用HMM的原生应用程序、容器和虚拟机将受到严重影响如果直接使用HMM而不进行内存管理，性能会下降，因此，参考我们在2.2节中推断的系统需求，FlexHM必须灵活处理不同云服务租户对异构内存使用和优化目标的复杂且差异化的要求。

“不同云服务租户对异构内存使用和优化目标的复杂且差异化的要求”到底是怎么个差异和复杂化，这个问题反应的操作系统层面时又是什么问题，哪些瓶颈？”由于原生云系统上的应用程序、容器和虚拟机具有不同的内存资源需求和差异化的内存访问模式”云提供商在一台物理机上，应该是提供了差不多的应用的吧。

HMM 管理的一个简单的想法是扩展当前的内核级内存管理策略来处理内存密集型云工作负载的 HMM 管理和优化需求。然而，这种设计可能有几个缺点。一方面，由于原生云系统上的应用程序、容器和虚拟机具有不同的内存资源需求和差异化的内存访问模式，操作系统内核很难设计一个全域策略来有效地管理和优化 HMM 差异化工作负载。如果我们在内核中设计并采用多种HMM管理策略，那么就会使原有的内核内存管理功能严重复杂化，牺牲代码维护的便利性，最终损害内核的稳定性。

在设计 FlexHM 时，我们选择了用户与内核级合作的 HMM 管理和优化设计。具体来说，我们只在 FlexHM 内核中添加了几个基本的 HMM 管理策略，以确保从操作系统的角度来看（第 5.1 节）内存分配和管理功能是正确的。内核 HMM 管理通常会在新应用程序、容器或虚拟机在 FlexHM 系统上初始化时触发，因此这种管理是针对每个工作负载本身的粗粒度管理，而不是运行时管理功能。此外，我们在 FlexHM 中设计了一种更精细的运行时 HMM 管理机制，通过用户空间管理器与内核之间的交互，提供灵活高效的 HMM 管理，并可采用定制的管理策略（第 5.2 节）。

5.1 Memory Management in Kernel

我们在 FlexHM 内核中添加了与两级 NUMA 设计相对应的三种基本内存管理策略，以便内核可以明智地进行内存分配和管理： (1) 如果新应用程序或来宾 VM 初始化，则内核默认从DRAM对等节点分配，而不是按照 NUMA 交错策略分配页面（具体来说，如果 DRAM 节点中没有内存，则页面分配直接落在 SMM 节点上。） (2) 运行在一个peer NUMA原生应用程序或VM显式地从peer NUMA节点中分配页面。如果此对等节点中没有内存，则内核将从具有相同 NUMA 距离的其他对等节点中分配内存。 (3) 页表PT被迫分配并保存在 DRAM 对等节点中。页表对性能至关重要，因为当应用程序对内存数据进行大量随机读/写操作时，页表会被频繁获取和更新，而在进行页表转换时，近一半的内存访问是由 TLB 错失引起的。

策略2不也很容易没有吗？你这个一半为什么没有实验、没有引用就这样直说了。就算你分在PM node 多次访问也会被迁移去DRAM甚至LLC.

而且，当内核发现 DRAM 对等节点没有可用空间时，会自动触发页面降级，类似于 kswapd 将页面从内存交换到磁盘上的交换分区，内核页面降级的频率与 kswapd 一样低，因此不会给内核内存管理带来严重的开销。如果操作系统有交换区，FlexHM还利用kswapd定期将SMM最不常用的内存数据移动到交换区。这有助于确保FlexHM上的进程不会分配即使操作系统的 DRAM 和 SMM 资源都被占用，也会影响交换区的内存资源，影响系统内存性能。

这些内核管理策略是简单、静态且通用的，适用于系统中的所有进程，这有助于保持操作系统内核的稳定。

5.2 Runtime Page Management

为了在FlexHM中进行更高效的HMM管理，除了内核管理之外，我们还需要更细粒度的管理机制。通常，在有内存页的操作系统中，每个内存页上每个数据的引用与每个CPU硬件的成本成正比当云应用程序长期对其内存页产生大量读/写操作时，缓存行会被加载和刷新，并且缓存行采用交错策略。因此，我们预测每个填充进程的内存读/写性能是相关的此外，由于当CPU缓存加载和刷新数据时，字节可寻址异构主存设备有不同的页面引用成本，因此整体性能与快速DRAM中页面引用成本的总和相关。因此，我们在FlexHM中设计了一种运行时页面管理机制，可以灵活决定快慢内存的使用百分比，并遵循定制的激进或保守的HMM管理策略。

在FlexHM中，我们设计了一个名为Memory-optimizer的用户级管理器来对每个原生进程、容器和虚拟机执行运行时细粒度的页面管理，该管理器以周期性过程分三个主要阶段执行页面管理：首先，在收集阶段，用户级管理器通过检查页面引用热度来计算页面引用频率；然后，在分析阶段，管理器进行页面热度分析，以预测运行时内存访问模式和数据引用最后，管理器根据资源利用率和定制的管理策略在HMM之间进行内存迁移，为Action阶段的不同工作负载场景提供优化。

FlexHM HMM页面管理的主要目标是，它可以根据收集的数据，将目标内存工作负载中最常引用的SMM页面识别为已识别的热SMM页面，将那些最空闲引用的DRAM页面识别为已识别的冷DRAM页面。所有参考信息尽可能正确。需要指出的是，识别的热SMM页面和识别的冷DRAM页面是测量值，可能与每个工作负载的真实热/冷数据存在一些差异。因此，FlexHM用户级别管理器旨在灵活地采取不同的管理策略，以提高运行时内存管理和性能优化过程中热/冷页监控、分析和识别的准确性。

对虚拟机的热页面的收集，问题是在于本机的页表量是虚拟机页表量的好多倍，还是会多出很多页表的扫描哩。还麻烦的点在于你页面迁移，如果在关键路径，重新建立页表映射关系之类的，挺麻烦哩。

我们用图 5 演示周期性页面管理程序。用户级管理器会在短时间 e 内定期重复该程序，包括收集、分析和行动阶段。具体来说，在每个 epoch e 中，管理器首先会以指定的时间间隔 i 进行热度收集，直到最大引用次数 r 为止，以监控和计算在一个 epoch e 中所有页面被引用的次数。r*i 时间（整个 epoch e 内）的页面热度信息，并预测目标工作负载和相同热/冷页面的数据分布。最后，管理器从相同的热 SMM 页面（以及相同的冷 DRAM 页面）中选择特定的内存大小，并进行页面晋升和降级，以优化目标内存的使用，从而达到自己的管理目标。最后，管理器休眠并等待下一个周期，以减少频繁的页面管理开销。下面三段将介绍更多细节。

首先介绍收集阶段，收集阶段对于监控页面引用信息至关重要，我们在FlexHM内核中设计了一个名为“kvm-ept-idle”的模块，将原来的管理更新为页表（PT）和扩展页表（EPT），具体增加了两个接口来检查和清除原生进程页面（包括原生应用程序和常规容器）或虚拟机（如QEMU）的匿名页面的PFN的Access位，接口可以调用分别来自内核空间和用户空间。因此，模块每次调用该接口时都会检查某个页面是否被引用。之后，如果该位为 1，内核模块会将 Access 位清为 0。每当重新检查该页面的 Access 位时，Access位的变化可以判断两次检查之间目标进程的页面是否被引用，在FlexHM设计中，用户级管理器以时间间隔i调用kvm-ept-idle模块的接口r次。我们在用户级管理器中为每个目标使用一个哈希映射来存储目标内存页面的HVA地址和对等节点信息，其中还记录了这些内存页面的页面引用类型（例如，读、写、执行） ）在Collection阶段，管理器可以根据目标进程的ProcMaps结构正确检查不同目标进程的内存页面，监控目标进程的页面引用信息。

其次，FlexHM将测量到的目标进程的页面引用信息进行拼接，并投影其页面引用数据分布，之前的工作已经证明，系统中，特别是云计算中的内存引用分布遵循Zipfian [15,47]，Gaussian [36]，或者Pareto[2]，如果页面引用遵循特定的数据分布，那么 FlexHM 就可以根据这种数据分布提高随机内存读写的性能。此外，FlexHM 还能针对不同内存参考分布的各种云工作负载灵活采用定制的页面管理策略。在 FlexHM 中，用户级管理器为每个目标维护一个数据结构，用于存储所有目标工作负载内存页的引用计数。页面引用信息存储在用户级内存区域，因此不会对有限的内核内存资源造成严重的内存占用。在”Collection”阶段之后，管理器可以计算不同虚拟内存区域（VMA）中所有页面的页面引用计数，并将其从 r 到 0 排序。然后，FlexHM 可以分析包含最常引用页面的虚拟内存区域，并预测工作负载遵循一定的数据分布。然后，管理器会检查这些页面是否位于 DRAM 或 SMM 对等节点中，并分析确定的应移动的热 SMM（和冷 DRAM）页面的总大小。

最后，在操作阶段，管理器可以通过调用 DRAM 或 SMM 对等节点之间的 move_pages() 系统调用，将相同的热 SMM 页面提升到 DRAM 节点，并相应地将具有相同大小的相同冷 DRAM 页面降级到 SMM 节点。 DRAM 和 SMM NUMA 对等节点之间的通信会占用 DRAM 和 Optane 内存硬件的部分内存带宽，因此管理器会休眠并等待一段时间，直到下一个周期管理纪元，以避免较高的管理开销。

5.3 Flexible Management Policies

在 FlexHM 运行时页面管理中，用户级管理器在 r∗i 时间的页面引用分布投影作为 epoch e 中热度分布的代表，并最终投影出目标工作负载的数据引用分布。如果工作负载在其生命周期内具有相对稳定和有规律的内存访问模式，那么每个时间点的投影将非常准确。而如果工作负载由多个进程产生，且其内存模式在短期内不稳定，那么如果工作负载显示出非常不规则的内存访问模式，管理器可能会在不同的时间段显示不同的热/冷页面。因此，使用每个纪元的数据分布预测并不准确，而且会导致一些不必要的热/冷页面移动，从而无法有效优化性能，并带来高昂的管理开销。

FlexHM 为用户级管理器中的i、r、e参数的灵活调整机制，以便设计和定制不同的页面管理策略。就时间间隔而言，使用较小的时间间隔 i 可以增加页面热度收集的频率，并有助于提高热度测量信息的准确性。不过，这可能会给页表或 EPT 参考带来额外开销，并降低系统内存性能。同样，使用较小的 epoch 可以增加页面移动频率，从而更好地利用 HMM 内存资源，提高性能。不过，这可能会给系统内存带来额外开支，因为 DRAM 和 SMM 对等节点之间的页面移动会占用大量内存带宽。此外，较大的 r 参数有助于提高分析和描述页面引用分布特征的准确性，但使用较大但不合适的 r 会降低页面移动的灵敏度，损害管理效率。

一种是激进策略，尝试将所有已识别的热页从 SMM 提升到 DRAM 节点，并在每个 epoch 中专门降级已识别的冷页；另​​一种是保守策略，仅提升一定比例的已识别热页并降级已识别的冷页。每个epoch中冷页的比例相同。对于一些内存访问模式稳定的内存工作负载，激进策略可以立即达到异构内存的最佳资源利用率，并减少长期运行时页面管理开销。对于一些内存热度较高的密集工作负载是不规则的，选择保守的迁移策略优于激进的策略，主要原因如下：（1）大量页面的频繁页面迁移可以优化目标工作负载的页面引用延迟，但会产生严重的迁移延迟开销。（2）每个epoch收集到的页面热度可能会有很大差异，我们需要用它来预测未来的内存引用分布，保守的策略有助于提高预测精度，优化管理效率。（3）页面迁移过程会占用内存带宽，保守的页面迁移可以减少迁移过程与目标工作负载之间的带宽干扰。因此，FlexHM 的内存优化管理器还提供了一个参数 “max_migration_size”，用于决定每个 epoch 之后需要在 DRAM 和 SMM 之间迁移的已识别热/冷页面的百分比，以配合 i、r、e参数配合使用。我们将在第 6 节中介绍参数选择，并在第 7.5 节中通过实验来评估在相同冷/热页面的百分比方面，我们应该选择激进还是保守的策略。

5.4 Memory-optimizer task-refs and sys-refs Tools

当优化目标工作负载是主机操作系统或客户计算机上的单个应用程序时，我们开发了用户级内存优化管理器的任务引用工具，用于内存性能和使用优化。针对进程（包括qemu-kvm进程），我们开发了sys-refs工具来提供多进程的优化，sys-refs还可以从全局角度管理FlexHM系统的所有进程。

task-refs工具利用目标进程的pid为单个原生工作负载或虚拟机工作负载提供定制化的性能和资源利用率优化，在启动task-refs工具之前，云管理员可以与云服务租户达成一致优化目标；例如，task-refs 可以通过在 HMM 页面上提供运行时性能监控并触发 DRAM 和 SMM 对等节点之间的页面迁移，使用固定比例的 HMM 来优化云工作负载的性能，或者可以从 DRAM 中移动冷数据将节点转换为SMM节点，以优化HMM资源利用率，并为每个云工作负载提供更实惠的价格。task-refs可以灵活接受间隔参数i，最大参考参数r，epoch参数e和“max_migration_size”来定制不同的管理策略。

如果系统面临多个应用程序或虚拟机产生的复杂内存工作负载，从而导致系统内存干扰和短缺，那么我们设计一个功能更强大的sys-refs工具来同时优化不同进程的内存，以在分配时达到全局优化结果多个工作负载的异构内存资源。算法1描述了sys-refs如何工作的基本过程。sys-refs可以接受多个目标工作负载的描述，例如“qemu-system-x86_64”，为所有虚拟机提供管理运行在FlexHM系统上，如果系统管理员没有指定任何目标，那么sys-refs可以根据pids为所有系统进程提供优化。

与task-refs工具类似，sys-refs可以接受参数，针对不同的优化目标定制不同的HMM管理策略，并且sys-refs工具可以动态更新页表或EPT不同时刻的热度收集间隔参数i根据实际测得的每轮行走时间和页面热度变化进行行走，如果测得的行走时间远小于采集间隔，且每次页面扫描差异较小，那么sys-refs可以放大扫描间隔，因为整个系统是可能面临内存工作负载较低，或者如果一轮测量的行走时间很长，并且每次页面扫描在虚拟地址上显示出非常不同的热页分布，那么 sys-refs 可以缩小扫描间隔参数以获得更准确的参考热度。当内存密集型工作负载空闲且内存引用分布没有变化时，sys-refs工具可以动态放大 epoch 参数 e，以减少运行时 HMM 管理开销。

6 FLEXHM IMPLEMENTATION

FlexHM的实现在Linux系统上实用，并于2018年开源。具体来说，FlexHM内核是在Linux内核上修改的，开源于，此外，FlexHM用户级管理器的原型代码。

内核实现对于Optane内存来说是实用的，并且基于Linux开源了1000多行代码，没有对硬件BIOS和用户空间应用程序或虚拟机进行任何修改，从而成功支持全虚拟化。具体来说，我们现在添加了Optane将内存作为慢速主内存类型放入 e820表中，并修改acpi/numa模块，以便我们可以将 SMM 设备存储到 NUMA 对等节点中并扩展SRAT表[48]。类似的实现后来已合并到 2020 年的 Linux 5.4 中。这两级 NUMA 设计基于这种透明的内存实现。此外，我们扩展了内核mm/pgtable内存管理，以强制__get_free_pgtable_pages在为新页表结构分配新内存时从 DRAM 对等节点获取页面。

这样应该就不用热插拔了。

我们在新的kvm-ept-idle内核模块中实现了内存访问信息的收集，对于原生应用程序，我们实现了一个名为mm_idle_walk_range的接口，该接口可以扫描页表并根据访问位检查所有页面的 Access 位。单个应用程序的虚拟地址区域，如果操作系统没有使用透明大页（THP）并且应用程序也没有使用大页，那么所有数据读/写操作都工作在4K页上，PTE的Access位可以表示参考信息。否则，1G 或2M PT条目的 Access 位可以代表数据读写操作的参考。由于 Linux 内核实现了 walk_page_range 函数，可以在其虚拟内存中递归地遍历进程的五级 PT地址范围 ，我们将 walk_page_range 的符号导出到用户空间并重用 mm_idle_walk_range 中的函数，以便接口可以扫描 PT 并检查 4K 页的 PFN 访问位，直到它触及页表项（PTE）（或 1G 页，直到页面上层目录（PUD），2M页面直到页面中层目录（PMD））。

对于guest机器，我们首先将匿名页面的HVA转换为GFN，然后使用EPT中的翻译信息将GFN转换为GPA，然后，我们实现一个ept_idle_walk_hva_range接口来接收匿名页面HVA作为输入，并检查匿名页面的引用信息kvm-ept-idle 中的 guest 页面。我们实现了一个ept_page_range，它在其虚拟地址范围内递归地遍历 guest 的五级 EPT，直到检查访问位修改。此外，当模块完成每一轮时，我们使 TLB 无效。 EPT遍历确保硬件正确地清除和设置超级热页的访问位.为了减少PT/EPT遍历的时间开销，如果发现高级PMD空闲，我们会跳过整个512个PTE。

为了灵活高效的HMM管理和性能优化，我们用3000多个c++代码实现了一个名为Memory-optimizer的全功能用户级管理器，该项目是开源的，它提供了运行时页面管理功能，用于优化单个工作负载（例如，应用程序或访客机器）或优化FlexHM系统上的所有进程。我们为不同的页面管理策略提供了多种参数选择。当遵循激进策略时，我们选择10作为参考参数r，0.1秒作为间隔i，并且10秒为一个epoch e，对于系统只使用4K页，没有大页（也没有THP配置）；对于使用2M/1G大页的系统，我们使用6作为参考参数r，以避免大多数情况下的写放大问题此外，由于管理器将提升所有相同的热 SMM 页面并降级在每个时期分析的所有相同的冷 DRAM 页面以进行积极的页面管理，因此需要移动页面的百分比 100% 等于相同的页面设计保守策略时，对于仅使用 4K 页的系统，我们选择 20 个引用作为 r，0.1 秒作为间隔 i，20 秒作为一个 epoch e；对于使用 2M/1G 大页的系统，我们选择使用 10 秒作为一个 epoch e。另外，当遵循保守的管理策略时，管理器在每个 epoch 中最多只选择 1/2 相同的热/冷页面进行页面移动。

7 EVALUATION

在评估部分，我们进行了全面的实验来评估FlexHM如何灵活高效地管理云工作负载的HMM资源。
评估内容有助于回答以下问题：

• 与使用 DRAM 或 Optane 内存相比，在 FlexHM 上使用 HMM 资源时云工作负载的内存性能如何？ （第 7.2 节）
• FlexHM的HMM利用率管理和性能优化效率如何？ （第 7.4 节）
• 与之前的HMM系统以及Optane的MM模式相比，FlexHM如何提供性能优化？ （第 7.3 节）
• 为什么要支持FlexHM中的灵活管理和优化策略适配（激进与保守策略的讨论）？ （第 7.5 节）

7.1 Experiment Environment

在实验中，我们设置了表 2 所示配置的硬件环境。所有实验中的 SMM 设备都是真正的英特尔 Optane 内存。我们在使用 Linux 4.20 内核的 Ubuntu 18.04 主机上编译了 kvm-ept-idle 内核模块。为了测试原生云进程的性能，我们直接在主机服务器上运行内存密集型基准测试。为了测试云虚拟机的性能，我们在使用通用内核的 Ubuntu 18.04 系统的 qemu-kvm 客户机中运行基准测试，因为 FlexHM 支持完全虚拟化，客户机无需修改内核。

what?! 4.20也让过？

我们将介绍评估实验中的微型基准和应用基准。首先，我们选择 Sysbench [27] 作为微基准，它可以产生非常密集的高并行随机读写操作，占用异构内存硬件的峰值带宽。Sysbench 可以对内存中的数据产生大量随机读/写操作，而且 Sysbench 内存测试的参数对我们评估 FlexHM 对差异化云工作负载的 HMM 管理效率非常友好。值得一提的是，Sysbench 有一个 memory-block-size参数，表示 Sysbench 在一个数据数组上创建随机内存访问，该数组的大小为 memory-block-size；它还有一个 memory-total-size参数，可以确定 Sysbench 在整个基准测试过程中随机读取或写入操作的内存总大小/内存块大小次数。我们的 Sysbench 基准的随机内存引用遵循近似生成的高斯分布，确保 80% 的随机引用位于数据分布期望值的 20% 对称区间内。我们在 32 核 68 G 客户机上运行了几组 1 线程和 32 线程 Sysbench 基准，以模拟对客户机工作负载的管理，并在服务器上执行了几组 1 线程和 32 线程本机 Sysbench 进程，以演示对原生服务或容器的管理。Sysbench 是使用 64Gmemory-block-size和 2T memory-total-size的global随机内存参考进行的随机读/写实验。

我们选择Memcached [8]（内存数据库）（使用YCSB框架[3]在Memcached上生成Zipfian分布工作负载）和Ligra [45]（图计算）作为应用程序基准测试的代表。

Memcached 是一个高性能的分布式内存缓存系统，旨在加速动态网络应用程序，提高数据库性能。我们将 Memcached 服务器设置在 64 G guest 中，作为云服务器基准，guest 内存由服务器 Socket 1 上的 NUMA 对等节点分配。我们在 Socket 0 上绑定了 YCSB 多线程生成器，并通过 40 Gb 双端口网卡向 Memcached 服务器发送操作。具体来说，YCSB 客户端生成的每个操作都在 100K K-V 条目上运行，我们在 Memcached 中存储了 500K 条目，因此所有数据都占用了 64G guest 中的 52G 内存（包含元数据）。对数据进行 K-V 操作的随机密钥选择遵循从 0 到 500K 的 Zipfian 分布，我们手动设置为 80% 的引用位于前 20% 的数据中，数据热度与 Sysbench 设置类似。

另一个应用程序基准是图计算框架 Ligra [45]。图计算是云计算中典型的内存密集型工作负载，图计算框架将非常大的图加载到内存中，然后运行计算算法。当在不同的迭代中计算时，大图中的数据可能会以不平衡的数据分布获取。我们分别在Ligra（一种用于共享内存的轻量级图处理框架）中运行BFS（广度优先搜索）、MIS（最大独立集）[22]和PR（PageRank）[39]。我们在 Ligra 中对具有 160M 顶点的随机生成图运行算法，该图在 64 G 虚拟机中消耗 62 G 内存用于内存计算。

7.2 Overall Performance with Different Ratios of HMM

7.2.1 Micro Benchmark – Sysbench

我们在不同组中精确固定了 Sysbench 实验的 DRAM/SMM 使用比例，包括全 DRAM、DRAM: SMM = 1:1、1:2、1:4 和全 SMM（全 Optane）配置。值得一提的是，由于我们要将 FlexHM 的性能与基线进行比较，我们使用了 numactl 和 taskset 命令来绑定客户机或服务器 Socket 1 内本机 Sysbench 进程的 CPU 和内存。（虽然 FlexHM 上的内存优化器可以轻松设置 DRAM 和 Optane 的 HMM 资源比例，但原生 Ubuntu 系统基线需要设置一些假的 NUMA 节点[26]，然后使用 numactl 生成 1:1、1:2、1:4 的 HMM 比例）

为啥要设置假的。这篇写的也太烂了吧，是给评委塞钱了吗……不翻译了。

此外，FlexHM 上的本机 Sysbench 实验的性能结果如图 6(c) 和 6(d) 所示。原生 Sysbench 性能还表明，FlexHM 系统上的原生应用程序可以在不同的 HMM 比率下实现令人鼓舞的性能，例如，在 1:1 比率配置的 32 线程 Sysbench 中实现全 DRAM 基准的 93% 以上的读取性能。这些实验表明，如果想要节省昂贵的 DRAM 成本，FlexHM 上的内存工作负载可以通过选择不同比率的 HMM 来获得有希望的性能，而不会严重降低性能。总之，Sysbench 基准测试表明 FlexHM 系统可以为来宾或本机工作负载提供高效的 HMM 管理。

总的来看，可能这篇文章由于是期刊的原因，大部分目光还是放在了傲腾PM上。同时提出的迁移策略和方案在近几年的会议论文中都有实现，所以现在来看创新性是欠缺的。另外作者的文章写的非常大概，对实现细节和策略设计都写得不太清楚，一些重复的“老生常谈”的话术倒是挺多。在评估方面，没有看出到底是作者的采样策略对热页面有效捕获、还是迁移很及时等能具体体现性能提升原因的评估实验。这篇文章区别于其他分层内存设计的最大亮点在于针对云计算（云原生、容器、虚拟机）来做设计，然后除了对虚拟机EPT的采样设计、对内存访问符合高斯分布的预测（也没说怎么实现，这个特性要怎么用，就是说的很大概）以外，在系统设计中并没有体现针对性，这也造成笔者对于到底性能怎么就提升了的疑惑。感觉是披了一层云计算外衣，做的还是分层内存的那几个操作。也可能笔者水平不足，还不能领悟其中精髓。