论文：https://www.pdl.cmu.edu/ftp/NVM/tmo_asplos22.pdf
内存是数据中心最大的瓶颈。百度也是如此，因为内存不足，导致大量机器cpu空闲但是利用率无法提升的主要原因
这篇论文的思路和 google 的 software-defined far memory 思路几乎是一样的，都是把 colder memory 卸载到 cheaper memory 上
google 论文是19年发表的，实际上项目2016年就已经上线了
facebook 论文是22年发表的，线上已经运行一年多。另外，论文里也隐约的提了，facebook就是在google的基础上做的，但是发现效果和 google 说的不一样，于是做了很多改进。如果我们要落地，也会有类似的问题。
1. INTRODUCTION
下文所有对比的地方，我简称：
- google的方案，g-swap
- facebook的方案，tmo
现状：
cpu的发展速度比memory要快
随着AI算法的发展，业务对内存的需求正在快速膨胀
硬件上，nvm和nvme ssd等技术的出现，Non-dram cheaper memory 开始越来越多的被使用
还有 CXL 这种 non-DDR memory bus 技术，可以接近 DDR 的原生性能
方向：内存分层技术，不管是 google 的 software-defined far memory 也有还是 facebook 的 TMO（透明内存卸载），本质上都是将低频访问的内存卸载到低速设备上
With memory tiering, less frequently accessed data is migrated to slower memory.
g-swap的一些问题：
- 核心是压缩
- 非常简单
- 好处：不用解决异构这些复杂的问题（感觉解决了？做了负载分类）
- 坏处：不利于最大化的 memory-cost saving
- promotion rate 的设定依赖离线分析
- 所有应用的 promotion rate 是一样的。没有考虑不同业务对内存的敏感性，以及不同分层设备的 performance（后者其实有简单的考虑，具体的 P% 的设备就取决于 far memory 到 near memory 的性能表现）
- g-swap的观点：为了保证应用程序的性能，memory offloading 应该控制在一个预先配置好的比例下面
- tmo的观点：facebook 对它们部署规模最大的程序，发现，在一些高速设备上，提高 memory offloading 比例，可以提高性能。 –> 反人类假设？？
为了解决这些问题，facebook 提出了 tmo 方案，优点：
- 核心是卸载（但是卸载的backend 支持 compressed memory pool，也支持 NVMe SSDs）
- 不需要离线分析，依赖 PSI 的反馈，直接单机决定不同的 offloading 比例。不依赖app的任何先验知识（g-swap的方案就有一个冷启动问题，新app默认不回收任何内存）
- PSI accounts for application’s sensitivity to memory-access slowdown（这里其实是比较误导的，facebook认为psi观测出来的内存延迟一定是对业务敏感的，但是实际上不同的业务对延迟的敏感性是不一样的，简单来说这个是充分不必要条件）
收益空间：20-32% 收益，百万服务器，其中7-19%由应用贡献，13%由sidecar等基础服务贡献
2. MEMORY OFFLOADING OPPORTUNITIES AND CHALLENGES IN DATACENTERS
2.1. Memory and SSD Cost Trends
内存价格越来越高，SSD 相对涨幅不大
内存压缩可以优化很大一部分，但还不够。卸载到 NVMe SSDs不仅可以节省内存，还可以降低机器的功耗。
facebook目前线上的 NVMe SSDs 卸载，相比g-swap的compressed memory pool，3x slower但是有3%的cost降低收益
2.2. Cold Memory as Offloading Opportunity
不同app的cold内存比例不一样：
- cache服务，最近5分钟访问的内存占比81%
- web服务，最近5分钟访问的内存只有38%
平均 cold 内存(5分钟内没使用）比例 35%，大部分app都有19%~62%的卸载收益
但是我觉得论文这个地方，5分钟没访问，就标记为 cold page，有风险
实际的情况是：
- 这些cold page是很稳定的，5分钟不会访问，之后也永远不会访问
- 这些cold page不稳定，均匀分布在所有的page上。比如，所有的page都是平均6分钟才访问一次
按照这个定义，web服务的cold page有62%，但是如果考虑上面第二种极端情况。web服务在运行期间，任何1个分钟周期内，都有62%的内存访问处于slow模式，这个对业务是不可接受的
按照 g-swap 的方案，业务能忍受的 promotion rate 是 0.2%，按照上面2的极端情况，几乎没有可以压缩的cold page
不过，不同app的page的访问pattern目前几乎不可识别，所以 g 的方案是线上踩坑，静态设置参数。f的方案高级很多，根据psi直接在单击动态决定比例
2.3. Memory Tax
We identify the “datacenter tax” — a set of shared low-level software components that comprise almost 30% of all processor cycles in production datacenters.
有两种：
- datecenter memory tax：一些基础服务的 memory tax
- microservice memory tax：应用依赖的一些 sidecar 服务的 memory tax。比如一些通用的 rpc 框架，提供 proxy 和 routing 功能
整体上看，memory tax 占整体内存使用的20%，还是蛮大的。其中前者13%，后者7%
memory tax的性能sla很宽松（比app直接消耗的内存的sla低），这个是TMO项目启动的最原始的初衷
Notably, the performance SLA for most of the memory tax is more relaxed than that of memory directly consumed by applications. As a result, the memory tax was a prime target for memory offloading during our first production launch of TMO.
疑问：这种 memory tax 怎么统计？
2.4. Anonymous and File-Backed Memory
内存的两大构成：
- anonymous 匿名页，也就是通常 top 看到的 rss
- file cache，也就是 page cache，free -g 能看到
可以看下百度的，商业广告核心服务，基本都是 anonymous，很少 cache，搜索bs用大量的 cache
总的来说，anonymous 和 file-backed 都会考虑 offload
2.5. Hardware Heterogeneity of Offload Backend
支持2种 offload backend：
- NVMe SSDs
- a compressed memory pool
未来会考虑支持 NVM 和 CXL 设备（为啥不用 AEP）
NVMe SSDs 异构是个非常大的挑战
关注几个因素：
- SSD 寿命：仍有较大的空间
- 读写延迟：普遍在470us~9.3ms之间
compressed memory pool 没有这个问题
3. TMO DESIGN
总结下来，2个关键：
how much memory to offload -> 35%
what memory to offload -> memory tax
3.1. Transparent Memory OffloadingArchitecture
关键模块：
- senpai：监控workload内存压力，动态调整cgroup的offload水位
- psi：内核态的内存压力监控模块
- offload backends：
- zswap：压缩池
- swap pool：存放 offload 的 anonymous 内存
- file system：存放 offload 的 page cache
问题：
3.2. Defining Resource Pressure
这里其实讲了很多 PSI 设计的初衷
系统本身是有一些指标能反映业务问题的，比如 pgmajfault。早期的offload其实是用这个指标来衡量offload的效果的，但是有2个问题：
- 程序启动会有大量的pgmajfault
- working set 转换（比如advserver的词表更新，也会有这个问题）
- 同样的pgmajfault，在sata和nvme上表现是不一样的（不同性能的backend）
其他：
- 只对runnable进程统计
- some：>= 1个进程处于stall状态
- full：所有runable进程处于stall状态
g-swap的promotion rate 的缺点：不同性能的backends，pgmajfault 对业务指标的影响是不同的
psi 记录3个时间（可以grep一下内核代码，实际上也只有3个地方会调用psi_memstall_enter()）
- 内存不足时回收内存的时间
- refault 之后 wait io 的时间
- 从 swap 设备加载内存的时间
业务性能指标 tm -> response_time，psi 也做了时间维度的归一化
3.3. Determining Memory Requirements of Containers
核心算法：
简单来说：
- 当前内存压力 > 压力阈值，offload关闭
- 当前内存压力 < 压力阈值，offload比例和压力比例，成正比
单次 offload 大小：
- 𝑟𝑒𝑐𝑙𝑎𝑖𝑚_𝑟𝑎𝑡𝑖𝑜=0.0005 -> 回收是逐步的，每次这么多，而不是一次性回收干净。The maximum is 1% of the total workload size in each reclaim period
- 𝑃𝑆𝐼_𝑡ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑=0.1%
周期：every six seconds，同时做了一些慢启动优化，单次 offload 变大是分钟级别的，单次 offload 降低是立即生效的
senpai 早期是通过调整 memory.max（后来改成了 memory.high，再后来就废了） 来触发内核的回收行为的，但是这样有一个问题，如果一个容器内存正在快速增长，就会被max限制住，一直阻塞到max被放开
后来增加了一个单独的 cgroup 接口 memory.reclaim，直接告诉内核offload多少内存
3.4. Kernel Optimizations for Memory Offloading
senpai 不会主动扫描所有的page是否是 cold page（g-swap方案）
而是依赖内核的内存回收行为来决定哪些是cold page，好处是节省了很多cpu，整机的0.05%（感觉这个很多啊，g-swap方案才单核得13%）
回收算法：
- 没有refaults时，内核只回收 file cache
- 有 refaults 时，内核从 file cache 和 swap 回收
回收和 offload 的区别时什么？？
4. EVALUATION
几个关键问题：
- 能节省多少内存？
- 怎么评估对 memory-bound 程序的影响？
- PSI vs promotion-rate 真的有优势吗？
- TMO 怎么做性能调优