引入一个新的沙盒状态来改善目前的权衡空间，其内存占用和启动性能介于冷态和暖态之间。可惜没开源好像
主要依赖于两点观察
- 同一个function的sandbox可能有高达85%的重复
- 即使在不同function的sandbox之间，我们也可以发现高达80-90%的重复
从本质上讲，可重用沙盒块(RSC)概念的作用是去除沙盒中的这些多余的内存块
Medes Overview
architecture
- controller
- 与客户的接口，通过该接口提交function request，并retrieve result
- scheduler，跟踪系统状态、扩缩容、决定是否回收sandbox
- 指纹注册表，它是一个哈希表，包含RSC的哈希值和它们在集群中的相应位置，用于重复数据删除
- 策略模块，存储策略参数，如延迟和内存限制
- node
- 守护程序，根据控制器的指令操作本地沙箱，并向控制器更新节点的状态
- 重复数据删除代理，根据控制器的指示（通过守护程序）为本地沙箱执行重复数据删除，并在请求被分配给本地沙箱时从重复数据删除状态恢复
workflow and lifecycle
workflow其实在Figure 4说的比较清楚了
- 客户端以RPC的形式向控制器的界面提交一个function request。
- 调度器根据其对节点状态的了解，选择一个可以运行该function的可用的warm或dedup沙盒，并将请求移交给所选沙盒节点上的守护进程。
- 如果这样的沙盒不存在，调度器默认要求内存占用最少的节点上的守护进程产生一个新的沙盒。在新沙盒的情况下，守护进程会准备好执行环境。
- 如果选择了dedup沙盒，守护进程会调用dedup代理来执行一个称为还原操作的程序，其中dedup代理通过从集群中的位置读回RSC的列表来重建沙盒。这个列表是在沙盒被放入dedup状态时产生的。
- 当一个function完成后，沙盒被移到温暖状态，在那里控制器可以决定是否对沙盒进行删除。该决定是根据管理员预先配置的策略模块做出的。如果控制器决定进行重复数据处理，重复数据处理代理会调用一个称为重复数据处理操作的程序。然后，代理根据指纹注册表中的RSC哈希值检查分块，清除状态中被认为是多余的部分，并记录从指纹注册表中获得的RSC的位置，在本地的dedup代理。
Medes允许运行一个自定义策略来决定沙盒从warm被转换到哪个状态，以管理内存和性能。 同时加了一个idle period，过了这个时间就变成dedup状态； 还加了一个keep-dedeop period，过了这个时间就销毁
Medes Dedup and Restore Operations
Dedup Op Deep-Dive
冗余识别粒度
一个trade-off，最后选择了64B
冗余消除粒度
肯定不可能以64B的粒度做，这样的话要保存的元数据就很多。 我们的关键见解是将冗余识别和冗余消除的粒度解耦。为了避免可扩展性瓶颈，我们默认将内存页作为冗余消除的粒度。 那么如何根据存储在指纹注册表中的RSC信息来识别冗余页呢？
页面指纹: We conduct a scan of each page over a rolling 64B window and select a 64B chunk as a fingerprint if it is last two bytes match a specific pattern We use five such value-sampled chunks per page.
基础页面: 重复块数量最多的候选页被选为基础页。重复复制的页面与基础页面的差异或补丁被计算出来
轻量级存储
不能把所有的sandbox都保存下来，太多了。因此，我们将平台上特定的温暖沙盒划分为 "基础沙盒"。只有这些基础沙盒的独特内存块被插入到注册表中。 （好像是一个function维护一个sandbox）
为了减少基础沙箱不可用的影响，每40个dedup sandbox，增加一个base sandbox
Restore Op Deep-Dive
还原操作包括使用存储的补丁和相应的基础页来重建沙盒。这步的要求就是快。
- 为了加速比如namespace重建和fork这种东西，Medes在重复复制沙盒之前执行了这些额外的耗时步骤。并且在内存中保存容器的checkpoints
- 恢复信息被放在dedup容器的本地
- 利用RDMA读取操作，直接从远程机器的内存中获取基页，这避免了使用远程CPU进行通信
Sandbox Management Policy
我们开发了一个政策，决定沙盒是否应该保持在温暖状态或dedup
策略这边其实比较好理解，就是一些速率的限制，然后加一些可调的限制（优先资源还是优先性能）