1. 概要
infiniswap 可以实现把一个机器的内存 swap 到另外多个机器上（1对多）
和其他实现相比，infiniswap 可以把开销做到很小，并且故障容错能力更强
- A transparent remote paging model for virtual machines @2008
- Swapping to remote memory over Infiniband: An approach using a high performance network block device @2005
- 还有一堆20+年前的论文（参考意义不大）
2. 架构设计
infiniswap 的组件其实就2个，非常简单：
- infiniswap-bd：一个虚拟的 swap 设备，其后端是远程内存
- infiniswap-daemon：管理本机对外提供的 remote memory（包括内存到虚拟地址的映射，等等）
这2个组件每个机器都会部署，类似于 daemonset
而且有个比较有意思的地方是，infiniswap 是去中心化的，它并没有一个中心式的管理组件（你看zombieland，中心式的管控组件就挺多的）
如下：
3. Efficient Memory Disaggregationvia INFINISWAP Block Device
这里主要是讲 infiniswap-bd 这个虚拟的 swap 设备怎么实现的
3.1. Slab Management
xx
3.2. Remote Slab Placement
重点
placement 算法必须满足3个目标：
- 同一个 swap 设备的内存必须分散到多个远程的机器上，以减少故障概率
- 考虑目标机器利用率，减少驱逐
- 必须是去中心化的
论文这里使用了一种叫 The power of two random choices 的算法（我爬了一下这个论文，这个还是19年FAST的best paper）
首先，对于每个 swap device，把目标机器分成两部分，Mold = 已用过了，Mnew = 没用过的
然后，先从Mnew里面选择1台机器，如果有，就用Mnew的，否则选择Mold机器（都是随机）
这个算法的优势，既可以实现去中心化，同时也不会因为随机性太强导致的 load imbalance 问题
3.3. I/O Pipelines
xx
3.4. Handling Slab Evictions
xx
3.5. Handling Remote Failures
xx
4. Transparent Remote MemoryReclamation via INFINISWAP Daemon
这里主要是讲 infiniswap-daemon 怎么管理 remote-memory 的
4.1. Memory Management
内存管理这块的主要工作就是决定机器上能提供多少远程内存（简称slab）
使用 EWMA（指数加权平均）来预测机器的内存使用：
β 默认是 0.2
所以机器的 free 内存 = total – Ucurrent
当 free 内存超过 xx 的时候，infiniswap-daemon 就会预先初始化一部分slab
实际上，这个地方作者其实做了简化处理，每个机器可提供的远程内存大小是固定的，就8g（上面一坨文字都是pr）
4.2. Decentralized Slab Eviction
当机器的 free 内存低于 xx 的时候，infiniswap-daemon 就开始释放一部分slab了
由于 A 机器访问 B 机器的远程内存，是直接通过 rdma 访问的 slab，并不会和 infiniswap-daemon 打交道，所以 infiniswap 并不感知 slab 内存的活跃程度
问题就来了：当要剔除E个slab的时候，怎么知道要释放谁呢？
思路：
- 粗暴的：遍历集群的所有 infiniswap-bd，获得slab的活跃度信息。但这个方案性能开销极大，还不如搞个中心式的组件
- 简单的：直接单机随机选择 e 个 slab，但这样剔除 busy slab 的概率就很大，实际测试表明，当集群的slab活跃度 > 10% 的时候，这个算法的效果就折半了
貌似都不太行，作者换了一种 Batch Eviction 随机算法，效果提升了不少（上面灰色线）
备注：
对于活跃的 slab，infiniswap-bd 周期性向 daemon 汇报活跃状态为啥不行？
5. 性能测试
volt-db 使用 50% 的远程内存，性能下降 30%，感觉也还可以
memcached 也类似
