Adbean's BlogPaper Reading: Software-Defined Far Memory in Warehouse-Scale Computers
Software-Defined Far Memory in Warehouse-Scale Computers
zswap 压缩内存的一篇论文，使用远端内存来降低成本
需要理解什么是 cold memoery，什么是 zswap 怎么做压缩
zswap linux manual, https://www.kernel.org/doc/html/v4.18/vm/zswap.html
使用了 ML 做 Autotunner
有意思的是，ASPLOS 19 在 Providence RI，Hoard (内存管理) 是当年的 Influential Paper Winner
至于 Far Memory
作用应该是很有前途的，除了 Google 提到的 WSC 仓库级负载，我觉得一些数据库也可以应用，尤其是论文提到 Bigtable 结合
除了 zswap far memo, 也有 application-integrated far memory (Brown), Fastswap(UCB) 等等比较有意思的
还有一篇 OSDI 22 best paper 看着有意思 MemLiner: Lining up Tracing and Application for a Far-Memory-Friendly Runtime
Abstract
随着内存需求的增加和技术扩展速度的减缓，仓库级计算机（WSC）的 total cost of ownership（TCO）面临着重要的挑战。
一个有前景的想法是通过添加一个更便宜但速度较慢的 “far memory” 层级来降低内存的 TCO，并使用它来存储不常访问（或冷）的数据。
然而，引入远端内存层级带来了新的挑战，包括动态响应工作负载多样性和变化、最小化容量闲置以及处理 brownfield (legacy) 部署。
TCO 总拥有成本，就是总成本？比如服务器价格、维护价格什么的吧
远端内存，能理解成类似 S3 吗？
问题就是兼容、动态负载什么的
我们提出了一种新颖的软件定义方法来实现远端内存，通过主动压缩冷内存页来在软件中有效地创建一个远端内存层级。我们的端到端系统设计包括新的方法来定义性能服务级别目标（SLO），一种在满足 SLO 的同时识别冷内存页的机制，以及我们在操作系统内核和节点代理中的实现。此外，我们还设计了基于学习的自动调优，以定期适应整个机群的变化，而无需人工干预。
自 2016 年以来，我们的系统已在谷歌的 WSC 中成功部署，服务于数千个生产服务。我们的软件定义远端内存在相对良好的访问速度（6 µs）下显著降低了成本（67%或更高的内存成本减少），并允许我们存储相当大比例的不常访问数据（平均 20%），从而在仓库规模上实现了显著的 TCO 节省。
Introduction
扩展 WSC 通常受限于在性能和成本效益方面扩展行为最弱的组件。
近年来，DRAM 已成为扩展 WSC 的关键瓶颈。设备级扩展速度的减缓（摩尔定律的终结[35]）阻止了每 GB DRAM 成本的降低[25, 27]。同时，内存计算的普及，特别是大数据工作负载，导致了 DRAM 需求的爆炸性增长。这两个趋势导致了近年来全球 DRAM 供应短缺，对 WSC 的成本效益扩展构成了严重挑战。
一个有前景的方向是引入第二级内存或远端内存，以降低内存拥有成本。远端内存是介于 DRAM 和闪存之间的一层，每 GB 成本低于 DRAM，性能高于闪存。通过在内存层次结构中引入远端内存并将不常访问（或冷）数据存储到远端内存中，系统可以在较低的 DRAM 容量下执行相同的工作，或者在每台机器上打包更多的工作，从而降低总拥有成本（TCO）。现代 WSC 及其上运行的应用程序具有以下特点，在部署第二级内存时提出了独特的需求：
- Near-zero tolerance to application slowdown, WSC 对性能成本比非常敏感，但应用程序的减速可能导致不可恢复的服务级别协议（SLA）违规，
- Heterogeneity of applications 在现代 WSC 上运行的应用程序越来越多样化
- Dynamic cold memory behavior WSC 在工作负载混合和/或利用率（例如，昼夜模式）方面表现出动态变化，导致每台机器可利用远端内存技术的有效内存大小发生变化。因此，近端和远端内存之间的最佳比例不仅取决于当前运行的工作负载，而且随时间变化。因此，希望降低闲置远端内存容量的 TCO 影响，或者在供应方面具有灵活性。
在本文中，我们解决了上述 WSC 拥有成本的挑战，
- 我们展示了对真实世界 WSC 的机群范围纵向描述，量化了每台机器可用冷内存量的巨大变化。我们发现，冷内存量在不同集群之间从 1%到 61%不等，即使在同一集群内，根据应用程序混合和一天中的时间，冷内存量也从 1% 到 52% 不等。这种范围需要灵活的远端内存供应，而不是固定容量的远端内存。
- 我们展示了一种软件定义的远端内存方法，该方法易于获取，提供灵活性 improves time to market, 使内存 TCO 变得可行。 具体来说，我们展示了 zswap[1]，一个 Linux 内核机制，可以将内存压缩存储在 DRAM 中，可以用于实现软件定义的远端内存，提供 single-digit µs of latency at tail.。我们还展示了我们主动将冷页移动到较慢的远端内存的方法，在从低访问率的页中获取内存容量方面表现良好，而不是在机器内存压力下的被动方法。
- 我们讨论了我们的方法的设计和实现。我们的控制平面包括（1）一个收集内存访问统计信息并将冷内存页交换到远端内存的内核机制，以及（2）一个根据应用程序行为控制内核机制激进程度的节点代理。我们的设计基于明确定义的服务级别目标（SLO），并且可以推广到其他类型的远端内存设备。
- 我们实现了一个基于机器学习的自动调优系统，根据机群范围的行为优化控制平面。它包括一个快速远端内存模型，估计在不同配置下整个 WSC 的远端内存行为，并由称为高斯过程（GP）Bandit[17, 21, 39]的机器学习算法指导设计空间探索。这使得整个系统能够适应整个 WSC 的长期行为变化
- 我们展示了来自真实世界用例的评估数据，包括在生产工作负载混合中的纵向研究和与 Bigtable[10]的案例研究。我们的系统可以迁移 20-30%的不常用数据，促进 4-5%的内存 TCO 节省（在 WSC 规模下为数百万美元），同时对多样化的应用程序影响微乎其微。我们的基于机器学习的自动调优器相对于基于启发式的方法，额外提高了我们系统的效率 30%。
这个 Gaussian Process (GP) Bandit 在调优里蛮常见的，数据库调优等等
但效果有这么好吗
Background and Motivation
Far Memory
远端内存是介于 DRAM 和闪存之间的一层，每 GB 成本低于 DRAM，性能高于闪存。在本节中，我们概述了先前研究中探讨的远端内存技术，并从 WSC 的角度讨论了它们的特点。
Non-volatile memory（NVM）是一种新兴的内存技术，其实现了比 DRAM 更高的密度（因此每 GB 成本更低）和基于新材料的数据持久性。迄今为止，相对于 DRAM，大多数 NVM 技术显示出更高的延迟（从数百纳秒到数十微秒）、更低的带宽（单数 GB/s）以及读/写不对称性（即写入比读取慢）。在访问接口方面，市场上主要有两种类型的 NVM 设备：内存总线（例如，NVDIMM-P [37]，Intel Optane DC 持久内存 [20] 等）和 PCIe 总线（例如，Intel Optane DC SSD [20]，三星 Z-SSD [38] 等）。两者的主要区别在于，前者允许以缓存块粒度对 NVM 进行加载/存储访问，而后者则通过类似于存储设备的页面粒度访问接口，数据在访问之前必须从 NVM 复制到主内存。因此，前者通常提供对存储在 NVM 中的数据的更快访问，但需要 CPU 端的硬件支持。许多当前的 NVM 设备仅以固定预设大小提供。这可能会在 WSC 的上下文中导致资源闲置。
Remote memory. 内存分解[30]是一种使用远程机器的内存作为交换设备的方法。它通过利用远程机器中的未使用内存[18, 29]，或通过构建仅用于为许多机器提供共享内存池的内存设备[30, 31]来实现。这两种实现方式都通过在集群中的机器之间平衡内存使用，减少了每台机器过度配置内存容量的需求。访问远程页面需要一到数十微秒的时间，具体取决于集群大小和网络结构速度。在 WSC 的上下文中，远程内存有一些有趣的挑战需要解决，然后才能部署以实现内存 TCO 节省[6]。首先，将内存页面交换到远程机器会扩大每台机器的故障域，使集群更容易受到灾难性故障的影响。其次，在离开机器之前，必须对正在交换的页面进行加密，以符合 WSC 应用程序处理敏感信息时通常设定的严格安全要求。第三，许多 WSC 应用程序对尾部延迟敏感[7]，但对于集群或机架来说，限制尾部延迟比对单台机器更难。
远端内存：容错性？安全性？
Far Memory in a Real-World WSC: Opportunities and Challenges
有许多方法可以定义内存页的冷度。我们关注基于以下两个原则的定义：（1）通过将超过 T 秒未访问的内存页分类为冷页，来体现时间局部性的价值；（2）通过测量对冷内存页的访问速率（称为提升率），作为远端内存对应用程序影响的代理。这两个原则是我们冷页识别机制的基石（在第 4 节中解释）。
图 1 显示了在不同 T 值下，WSC 中运行的每个作业的冷内存百分比和提升率的机群范围平均值。由于较低的 T 值会在内存页生命周期的较早阶段将其分类为冷页，因此它会识别更多的冷页。在最激进的设置 T = 120 秒时，我们观察到平均 32% 的内存使用是冷的。这一大比例的冷内存展示了远端内存在真实世界 WSC 中的巨大潜力。
另一方面，随着系统在识别冷内存方面变得更加激进，远端内存的性能开销也会增加。在 T = 120 秒时，应用程序平均每分钟访问其总冷内存的 15%。根据近端内存和远端内存之间的相对性能差异，这一访问率可能会显著降低应用程序性能，抵消远端内存的 TCO 节省。
冷内存百分比与性能开销之间的这种权衡关系促使需要一个强大的控制算法，该算法可以在最大化前者的同时最小化后者。在本小节的其余部分，为了简单起见，我们将假设 T = 120 秒。
图 2 展示了在 10 个集群中每台机器的冷内存百分比分布（即冷内存总大小除以每台机器的内存使用量），**每个集群最多包含数万台机器。**我们发现，即使在同一集群内，冷内存百分比也从 1% 到 52% 不等。如果我们将每台机器的远端内存容量配置为总内存容量的 20%，那么一些机器将有比可用远端内存容量多 30%的冷内存。另一方面，配置为 50% 将导致一些机器的近端内存容量不足，导致过多的性能开销。从 TCO 的角度来看，这两种方法都不理想。
此外，应用程序行为增加了另一个维度的可变性。图 3 描述了每个作业中冷内存百分比的分布（在作业执行过程中平均）。对于前 10%的作业，至少 43%的内存使用是冷的；对于后 10%的作业，这一比例降至低于 9%。这种异质性，加上现代 WSC 上运行的大量作业，使得为每个应用程序优化远端内存变得不切实际。
总之，将冷内存存储到更便宜但速度较慢的远端内存具有在 WSC 中节省 TCO 的巨大潜力。但要实现这一点，系统必须（1）能够准确控制其激进程度，以最小化对应用程序性能的影响；（2）能够适应不同机器、集群和作业之间冷内存行为的可变性。
Software-defined Far Memory
We show a software-defined approach to far memory implementation, which we have adopted and deployed at Google.
特别是，我们提议采用 zswap [1]作为现成的远端内存解决方案。在 Linux 内核（3.11+）中，zswap 作为一个交换设备，旨在避免机器内存耗尽。
zswap 在手机端使用比较常见，经常用于内存压缩保留更多的 RAM，比如一个应用最近很少使用的页面，可以被压缩释放，节省内存
除了压缩，也用于 swap，压缩页到压缩池而不是放回磁盘，等下次访问解压缩放回内存，减少磁盘 IO
使用 lzo, zstd 等压缩算法，
用时间换空间和成本的意思？
相反，我们采取了一种主动的方法，使用 zswap 在内存中存储冷压缩页，并在软件中实现远端内存。压缩内存页允许我们在内存中打包更多数据（即每 GB 成本更低），代价是增加访问时间。从 TCO 的角度来看，这与任何其他远端内存实现没有本质区别。
Advantages of Software-defined Far Memory
Reliability zswap 将故障域限制在一台机器内，将灾难性故障限制在单台机器上，同时避免了远程内存的安全性和可靠性挑战。此外，它不引入额外的硬件组件，简化了系统设计、实现、测试、部署和监控。
Time to deployment zswap 作为一种软件方法，可以以更短的时间和更低的成本部署，并且不需要跨供应商合作，因为不需要任何特殊硬件（例如 NVM） 请注意，部署速度对于 WSC 至关重要
No new hardware cost 与其他远端内存技术不同，zswap 通过用 CPU 周期（用于压缩和解压缩）换取内存节省。
Adaptive to dynamic application behavior WSC 中工作负载混合和内存访问模式的变化（第 2.2 节）导致每台机器和跨机器的冷内存大小发生变化。zswap 可以通过动态调整分配给作业的内存容量（通过压缩更多或更少的内存）来适应这种变化。即使在如此动态的情况下，zswap 仍然可以实现内存 CapEx 节省，因为平均跨数万台机器使内存节省在集群级别稳定，这是我们配置容量的方式（第 6.1 节）。这使得 zswap 与那些一旦部署容量就难以改变的远端内存解决方案有所不同。此外，它还使得在不改变硬件配置的情况下，更快地尝试不同设置成为可能。
缺点呢？
平常空闲的机器无法应对突发负载？稳定性？
Challenges in Software-defined Far Memory
WSC 中远端内存的控制机制需要（1）严格控制性能减速以满足定义的 SLO，以及（2）低 CPU 开销，以便最大化从远端内存获得的 TCO 节省。尽管 zswap 在 WSC 的远端内存设计中表现出有利的特性，但其控制平面并不满足上述标准。这是因为 Linux 内核中的 zswap 在启用时仅在直接回收（即当主机内存节点耗尽内存时）时触发，并尝试压缩页面直到有足够的空间避免内存不足的情况，从而暂停应用程序的分配。这种机制存在以下缺点：（1）由于 zswap 解压缩导致的性能开销是无限的，（2）最后一刻的突发压缩开销对尾部延迟产生负面影响，损害 WSC 应用程序的服务级别指标（SLI），以及（3）内存节省直到机器完全饱和时才实现。事实上，我们在部署过程中确实评估了这种方法，但观察到应用程序性能的显著下降，对 TCO 产生了负面影响。
此外，WSC 的 DRAM 中的每一条数据并不都适合通过压缩来节省，当 zswap 选择压缩这些数据时，会导致浪费的周期机会成本。例如，内存中的视频数据可能不像文本数据那样可压缩。
有些不能压缩？
因此，在本文中，我们设计了一个端到端的仓库级系统，该系统识别冷页并主动将其迁移到远端内存，同时将性能视为首要约束。关键问题是冷页有多冷？或者冷页的定义是什么？冷页识别算法的质量将影响内存节省和应用程序影响。
Cold Page Identification Mechanism
我们的目标是设计一个强大且有效的控制平面，用于大规模部署 zswap。与 Linux 内核中的 zswap 或其他交换机制一样，我们的系统在迁移近端内存（例如，DRAM）和远端内存（例如，zswap）之间的页面时，以操作系统页面粒度工作。这使得无需硬件修改即可采用远端内存。
与现有 zswap 机制的主要区别在于何时压缩页面，或何时将页面从近端内存迁移到远端内存。与 Linux 内核中的 zswap 不同，我们的系统在后台识别冷内存页并主动压缩它们，以便额外的空闲内存可以用于调度更多作业到机器上。一旦访问压缩页面，zswap 会解压缩页面并将其保持在解压缩状态，以避免反复产生解压缩开销。这些页面在将来变冷时再次有资格进行压缩。
压缩的是冷页面，
多出来的内存给谁用呢？
Definition of Cold Pages
我们的系统根据每个页面上次访问后的时间（简称为 age）来识别冷页。当页面超过 T 秒未被访问时，它被认为是冷的。我们称 T 为 cold age threshold，它决定了系统识别冷内存页的激进程度。我们基于先前的工作[28, 42, 46]设计了这一机制。
冷年龄阈值对内存节省和性能开销有直接影响。过早地将页面分类为冷页可能会将它们映射到远端内存，导致性能下降。我们的系统试图找到满足给定性能约束的最低冷年龄阈值，以便在明确定义的 SLO 下最大化内存节省，我们将在下文讨论这一点。
T 怎么找，和 SLO 有关？
Performance SLO for Far Memory
在 WSC 环境中，直接关联冷内存阈值对应用程序性能的影响是具有挑战性的，因为不同应用程序的性能指标具有多样性，这些指标本身可能从延迟敏感（例如，面向用户的网页前端）到吞吐量导向（例如，机器学习训练管道）不等。
Promotion rate 远端内存的性能开销来自于访问存储在远端内存中的页面（我们称这种操作为提升），由于远端内存中的页面一旦被访问就会迁移到近端内存，提升率等同于单位时间内访问的远端内存中唯一页面的数量。
Target promotion rate 不同的应用程序对提升率的性能敏感度不同。例如，在相同的绝对提升率水平下，小作业比大作业更有可能经历更高的性能开销，因为前者可能具有更高的远端内存访问比例。这需要一种方法来通过代表每个作业“大小”的指标来归一化绝对提升率。
为什么小作业可能更高性能开销？为什么具有更高的远端内存访问比例，是个 rate？
因此，我们设计我们的系统，使提升率保持在每分钟应用程序工作集大小的 P% 以下，这作为远端内存性能的服务级别目标（SLO）。
我们将应用程序的工作集大小定义为在最小冷年龄阈值（在我们的系统中为 120 秒）内访问的总页面数。每分钟的工作集大小作为作业内存带宽使用的代理，根据我们的评估，这与作业对远端内存访问的性能敏感度相关。我们的 SLO 确保应用程序的工作集不超过 P%来自远端内存，从而限制远端内存的性能开销。P 的确切值取决于近端内存和远端内存之间的性能差异。对于我们的部署，我们进行了为期数月的 A/B 测试，并在生产工作负载中通过经验确定 P 为 0.2% / min。在这个目标提升率水平下，作业的压缩/解压缩率足够低，不会干扰同一机器上的其他共存作业。
cold memory 越大 promotion rate 越大，
promotion rate：访问远端 cold memory 的频率
强制提升率低于目标值可以防止应用程序的突发解压缩，因为从定义上限制了解压缩速率。在极少数情况下，如果激进或相关的解压缩突发导致机器因解压缩压缩页面而耗尽内存，我们通过杀死并重新调度其他机器上的低优先级作业来选择性 eviction 。我们的 WSC 控制平面[40]为用户提供了一个 eviction SLO，在 18 个月的实际生产中从未被违反，同时我们实现了内存节省。
Controlling the Cold Age Threshold
为了确定满足提升率 SLO 的最低 Cold Age Threshold，我们估计应用程序在不同冷年龄阈值下的提升率。为此，我们在操作系统内核中为每个作业构建一个 a promotion histogram ，其中，对于每个冷页阈值 T，我们记录总提升率，这些页面比阈值 T 更冷。
作一个例子，假设一个应用程序有两个内存页 A 和 B，分别在 5 分钟和 10 分钟前被访问，并且两个页面都在 1 分钟前再次被访问。在这种情况下，提升直方图返回 T = 8 分钟的 1 次提升/分钟，因为只有 B 在 T = 8 分钟时会被认为是冷的，当两个页面在一分钟前被访问时。类似地，它返回 T = 2 分钟的 2 次提升/分钟，因为现在 A 和 B 在 T = 2 分钟时都会被认为是冷的。我们在第 5.1 节中讨论了我们的实现。
为什么 T 一定要低呢
虽然提升直方图让我们选择了过去最好的冷年龄阈值，但它不一定是未来的最佳阈值。Ideally, the control algorithm has to give us a stable threshold over time so as to reduce unnecessary compression and decompression costs. 同时，系统必须对应用程序活动的突然峰值做出响应，并避免长时间过度压缩内存。因此，我们的系统基于以下原则控制阈值：
-
它跟踪过去每个 1 分钟周期内的最佳冷年龄阈值，并使用它们的 K 百分位数作为下一个 1 分钟的阈值。通过这样做，它在稳定状态下将违反 SLO 约(100 - K)% 的时间。
-
如果最后一分钟的冷年龄阈值高于过去的 K 百分位数（即作业在过去一分钟的冷内存访问量高于过去行为的 K 百分位数），我们使用前者，以便系统能够快速响应应用程序活动的突然增加。
-
由于算法依赖于每个作业的历史记录，我们在作业执行的前 S 秒内禁用 zswap，以避免基于不充分的信息做出决策。
Calculating the Size of Cold Memory
我们机制的最后一部分是估计不同冷年龄阈值下的冷内存大小。为此，我们的系统为给定的一组预定义冷年龄阈值构建每个作业的冷页直方图。在这个直方图中，对于每个冷年龄阈值 T，我们记录至少 T 秒未被访问的页面数量。这些信息用于（1）估计作业的工作集大小（用于归一化提升率；见第 4.2 节）和（2）对不同冷年龄阈值下的潜在内存节省进行离线分析（第 5.3 节）。
System Implementation
在本节中，我们讨论了在操作系统内核和节点代理中实现的冷页识别机制，以及用于它的自动调优系统。我们基于 zswap（一个 readily available Linux feature）展示了我们的系统设计并进行了评估，但我们的设计可以推广到其他类型的远端内存技术，因为我们的控制平面不依赖于任何特定的远端内存设备。
图 4 展示了我们系统设计的高级图。在每台生产机器上，我们的定制 Linux 内核（第 5.1 节）和节点代理（第 5.2 节）调整冷年龄阈值并收集每个作业的统计信息。使用作业的历史数据，我们使用机器学习来调整节点代理的参数（第 5.3 节）。
不依赖硬件
Kernel
我们使用 Linux 的内存 cgroup（memcg）[2]来隔离 WSC 中的作业。软件定义的远端内存构建在 zswap 之上。我们运行两个全机范围的内核守护进程，即 kstaled 和 kreclaimd，以收集远端内存统计信息并将页面移动到远端内存。我们首先讨论我们的 zswap 实现以及在我们的生产环境中进行非破坏性部署所需的修改。
cgroup https://tech.meituan.com/2015/03/31/cgroups.html 美团的文章特别好
stale d
reclaim d
zswap
我们通过几个针对 WSC 部署定制的功能增强了上游 Linux 的 zswap 实现。我们使用 lzo 算法来实现低 CPU 开销的压缩和解压缩。
一旦 zswap 压缩了一个页面，它就会分配内存来存储压缩的有效载荷。我们使用 zsmalloc 作为压缩数据区域。我们为每台机器维护一个全局的 zsmalloc 区域，并在需要时由节点代理触发显式压缩接口。虽然每个 memcg 的 zsmalloc 区域看起来更直观，因为我们用 memcg 封装了作业，但它会导致每个 zsmalloc 区域不同程度的外部碎片化，因为 WSC 通常每台机器打包数十或数百个作业。我们最初使用每个 memcg 的 zsmalloc 区域的研究发现，每天有数千个实例的区域碎片化到负收益的程度。
zsmalloc 是一个基于 slab 的内存分配器，旨在有效地存储各种压缩级别的页面。 它以最少的碎片量实现了最高的存储密度。
在低内存条件下工作良好。zsmalloc 只能分配大小不超过 PAGE_SIZE 的对象
https://docs.kernel.org/mm/zsmalloc.html
memcg 是 Linux 操作系统中的内存控制组（memcg, memory control group），cgroup
为什么是 lzo？快
We compared several compression algorithms, including lzo, lz4, and snappy, and concluded that lzo shows the best trade-off between compression speed and efficiency.
根据经验，存储大于 2990 字节的 zsmalloc 有效载荷（4 KiB x86 页面的 73%）没有收益，其中元数据开销变得高于压缩页面的节省。当尝试压缩产生大于该有效载荷的页面时，我们将其标记为不可压缩并拒绝它。不可压缩状态阻止 zswap 尝试重新压缩该页面，并在 kstaled（见下文）检测到与该页面关联的任何 PTE 变脏时清除。
只压缩小页面？
当作业达到其内存限制时，我们关闭 zswap 而不是将其用作交换设备。这是因为 WSC 应用程序更喜欢“快速失败”并在集群中的其他地方重新启动，依靠其容错特性[7]，而不是在内核模式下浪费 CPU 周期试图避免作业抢占。它还使 zswap 与集群范围调度器的典型行为一致，当它们耗尽内存时，调度器会杀死尽力而为的作业。
当机器耗尽内存时，内核将在故障进程的上下文中使用直接内存回收。节点代理为每个 memcg 维护一个“软”限制，相当于其工作集大小（使用第 4.2 节中的方法确定），内核不会在此阈值以下回收。这保护了高优先级作业的工作集，并防止回收作业线程花费过多的周期进行 zswap，同时强化了低优先级作业“快速失败”的偏好。
kstaled
我们定期扫描页表项中存在的访问位，以推断页面是否在给定时间段内被访问[4, 19]。我们利用 kstaled，一个内核守护进程 a kernel daemon，基于访问位信息跟踪所有有资格进行内存回收的物理页面的年龄[28]。
在每个扫描周期内，kstaled 遍历进程页表以读取每个物理页面的访问位。如果页面的访问位被设置，kstaled 将相应页面的年龄设置为零；否则，它增加年龄。它还清除访问位以检测页面的任何未来访问。如果物理页面映射在多个页表中，kstaled 仅在任何页表中访问位未设置时增加年龄
我们的 kstaled 版本将页面的年龄存储在 perpage metadata structure 中，以便其他使用页面访问模式的内核组件（如直接回收）可以利用 kstaled 已经收集的信息。我们使用每页 8 位来编码页面的年龄。由于我们将这些位打包在 Linux 内核中已经维护的 struct page 元数据结构中，因此我们不会为跟踪年龄产生任何存储开销。我们以 120 秒的频率运行 kstaled。使用 8 位年龄，我们可以跟踪长达 8.5 小时（= 255 × 120 秒）的年龄。
每当 kstaled 更新页面的年龄时，它还会更新两个每个作业的直方图：（1）冷年龄直方图，一个页面年龄的直方图，跟踪页面未被访问的时间 T；（2）提升直方图，记录页面被访问时的年龄。这些直方图导出到节点代理，并用于确定冷页年龄阈值，如第 4.3 节所述。
To minimize the CPU overhead of kstaled, we empirically tune its scan period while trading off for finer-grained page access information.平均而言，kstaled 作为优先级较低的后台任务运行时，消耗不到一个逻辑 CPU 核心的 11%。
empirically?
kreclaimd
一旦节点代理使用 kstaled 构建的年龄直方图并设置冷年龄阈值，kreclaimd 将每个页面的年龄与页面所属作业的冷年龄阈值进行比较，并回收所有年龄超过阈值的页面。
我们通过将冷页面移动到 zswap 来回收 DRAM 中的冷页面，从而释放 DRAM 容量以服务热应用程序页面。访问时，压缩页面会被解压缩。kreclaimd 在任何其他应用程序未使用的空闲周期中运行，作为一个不引人注目的后台任务实现内存收益。
请注意，我们只考虑最近最少使用（LRU）列表[3]中的页面映射到远端内存。例如，如果页面被标记为不可驱逐或锁定在内存中（mlocked），我们不会将其映射到远端内存。这有助于我们避免浪费 CPU 周期在不可移动的页面上。
Node Agent
每台机器上运行的节点代理（在我们的集群管理系统中称为 Borglet [40]）动态控制每个作业的冷年龄阈值。使用第 4.3 节中描述的算法，它通过每分钟读取内核统计信息并计算过去一分钟的最低冷年龄阈值（不违反目标提升率），构建过去最佳冷年龄阈值的池。然后，它在每个作业执行开始后的 S 秒内启用 zswap，将阈值设置为池中下一个一分钟的 K 百分位数。节点代理定期将每个作业的冷内存统计信息从内核导出到外部数据库，以促进离线分析和监控。
ML-based Autotuner
我们的系统将前面讨论的 K 和 S 作为可调参数，以调整控制平面的激进程度。然而，手动一次性调整这些参数涉及在生产系统中进行多次迭代和 A/B 测试，这既冒险又耗时，并且容易受到工作负载行为随时间变化的影响。
据我们所知，这是首次将 GP Bandit 用于优化 WSC。
K 代表冷年龄阈值的百分位数
S 代表作业执行开始后的等待时间（以秒为单位），在这段时间内禁用 zswap。
省略 ML 内容，不过用 Bandit 调优 WSC 的想法真的很厉害，这一篇论文非常精彩，都是很简单的想法，但是效果很不错
不论是 lzo, zswap, cgroup 都是现有的，还是 bandit 调优，也都是存在很久的方法
估计也就 google 团队能遇到 wsc 中的现实问题，特定问题 特定解法，很 practical
Evaluation
cold memory coverage as a metric
我们将冷内存覆盖率定义为存储在远端内存（即压缩）中的总内存大小除以在最低可能冷年龄阈值（在我们的系统中为 120 秒）下的总冷内存大小。从概念上讲，这是存储在远端内存中的冷内存的百分比，并暗示我们的系统与上界有多接近，即所有在 120 秒或更长时间内未被访问的页面都可以存储在远端内存中而不会导致性能下降。
图 5 显示了随时间变化的冷内存覆盖率的机群范围平均值，并标注了相关的时间线。第一阶段（A 到 B）部署了 zswap，其静态参数值由有限的小规模实验提供。然后，在第二阶段（C 到 D），我们推出了我们的自动调优器及其参数值建议。
cold mem coverage 越高，意味着越多内存能释放出来提供调用
图 6 显示了前 10 个最大集群中机器的冷内存覆盖率分布。与第 2.2 节中的冷内存分析一样，我们观察到不同机器之间的冷内存覆盖率范围很大，即使在同一集群内也是如此。这展示了 zswap 在远端内存容量方面的灵活性优势。
不同任务的集群，coverage 表现也不错
虽然冷内存覆盖率随机器和时间变化，但集群级别的比率一直稳定，这使我们能够将 zswap 的冷内存覆盖率转换为更低的内存配置。在冷内存覆盖率为 20%，冷内存比率的上限为 32%（图 1），以及压缩页面的成本降低 67%（第 6.3 节）的情况下，我们的系统以透明的方式实现了 4-5%的 DRAM TCO 减少。这些节省是在性能 SLI 没有差异的情况下实现的，我们将在下文讨论。
SLI, indicator，指标
SLO, objective 基于 SLI，承诺质量，目标
SLA, agreegment 客户协议
Cold Memory Coverage
Performance Impact
我们使用两个指标来衡量我们系统的性能影响：提升率和 CPU 开销。前者是远端内存的性能 SLI（第 4 节），可以推广到其他类型的远端内存设备。
CPU 开销显示了使用 zswap 作为远端内存所消耗的周期。
promotion rate 在我看来倒是很难直观理解
我们通过几个月的 A/B 实验手动确定了 K 和 S 的值，这些实验来自我们根据经验猜测的几个候选配置。我们观察到两种情况下的提升率都非常低；提升率的第 98 百分位数每分钟低于工作集大小的 0.2%。这表明我们的冷页识别机制准确地将不常访问的页面分类为远端内存的有效候选者。 This demonstrates that our cold page identification mechanism accurately classifies infrequently accessed pages to be effective candidates for far memory
维持提升率低，就说明是真的压缩了那些 least 访问的
图的纵坐标很奇怪是 CDF of Job count，横坐标反而是 promotion rate 或者 CPU overhead
而且同样 cdf，promotion rate ML 方法增加了，说明还是手选好？但提升不多，说明训练拟合还行
压缩带来的 cpu overhead 也不是很多，都在 0.10% 以下
图 8 还表明，我们系统的机器级 CPU 开销也非常低，从 TCO 的角度来看，与整个 WSC 平均 20%的冷内存覆盖率（图 5）相比，这种 CPU 开销可以忽略不计。
Compression Characteristics
zswap 给系统带来了两种额外的成本。首先，压缩页面仍然存储在 DRAM 中，这使得实际内存节省取决于数据的压缩比。其次，压缩页面按需解压缩，这会在访问压缩页面时产生性能开销。本小节根据从整个 WSC 收集的统计数据量化这两个方面。图 9a 展示了每个作业中压缩页面的平均压缩比分布，不包括不可压缩页面，这些页面平均占冷内存的 31%。尽管 zswap 使用轻量级压缩算法来最小化其 CPU 开销，但它在中位数上实现了 3 倍的压缩比（即 67%的内存节省）。压缩比从 2 倍到 6 倍不等，这取决于应用程序特性。例如，多媒体数据和加密的终端用户内容即使在冷状态下也是不可压缩的。
视频处理的集群呢？
Decomp. Latency (μs) 不是很高，都是个位的
Case Study with Bigtable
最后，我们通过一个案例研究来量化我们的远端内存系统对应用程序级别性能指标（例如，每周期指令数[45]）的影响。我们的目标应用程序是 Bigtable[10]，这是我们 DRAM 的最大消费者之一，它将 PB 级的数据存储在存储中，并以内存缓存的方式为许多生产服务提供每秒数百万次操作的服务。
找个时间看 bigtable
但没懂这里和 bigtable 结合有什么显著区别， IPC 几乎不变，没有影响？
但是冷内存覆盖率还有 5-15% 表示也有提升，但是我想看更多 metrics，延迟，成本，为什么没有呢
Related Work
Conclusion
不需要硬件、不需要硬件远端内存、不需要可持久化内存
用 age 来追踪，而不是用数位等等
优点蛮多的，非常厉害的一篇论文
google 可能更注重不影响 SLA、性能和可靠性，这都是很 practical 的
至于为什么混入一个 ML 挺奇怪的其实。。可能那时候流行吧