dyweb
Catalyzer: Sub-millisecond Startup for Serverless Computing with Initialization-less Booting
本文基于的一个非常重要的观察：kernel 启动的时间在整个应用启动的生命周期里并不是最长的，更长的是 JVM 等运行时启动的时间。这个在业界所有的轻量虚拟化方案中都是一样的：
因此作者先用 gVisor 的 restore/recover 功能 https://gvisor.dev/docs/user_guide/checkpoint_restore/ 来用 restore 替换运行时的 init 过程（修改后的版本叫做 gVisor-restore）。这样改动后确实有提高，但是 restore 的成本还是挺高的。
gVisor-restore 的实现方式还不太看得懂，需要学习一下 gVisor 源码，看论文应该是通过一个 syscall 来劫持了调用，做了一些 save/restore 的操作
We add a new syscall in gVisor to trap at the entry point of serverless functions. We use the term, func-entry point, to indicate the entry point of a serverless function, which is either specified by developers or at the default location: the point right before the wrapped program invoking the handler function. The syscall is invoked by the func-entry point annotation and will block until checkpoint operation begins.
尽管用 restore 替换了 JVM 等 runtime init，restore 的成本还是挺高的，所以这篇文章最核心的贡献就是通过一些优化，把 restore 的成本再降低了一下。
Catalyzer 一共引入了三个 boot 类型，分别是 cold boot，warm boot 和 fork boot，他们的 latency 是不一样的。其中 cold boot 就是从前面提到的 func-image 直接 restore 一个 sandbox instance 出来。
warm boot 是 restore 部分 image，同时通过共享内存，从在运行的实例获得一些 state 来避免 restore 全部 image 的成本。hot boot 就是直接通过 Catalyzer 引入的一个新的系统原语 sfork 实现，latency 在文章里的说法是 1ms。
整个实现里，一共涉及四个技术，分别是 Overlay Memory，Seperated State Recovery，on-demand I/O reconnection 和 virtualization sandbox
Overlay Memory 因为不熟悉 EPT，不明白实现细节。效果如下：
Catalyzer maintains two layered EPTs for each sandbox. The upper one is called Private-EPT, and the lower one is Base-EPT. Private-EPT is private to each sandbox, while Base-EPT is shared and read-only. During a warm boot, Catalyzer directly maps the Base-EPT for the new sandbox with the share-mapping operation.
好的，谢谢
------------------ 原始邮件 ------------------ 发件人: "dyweb/papers-notebook" @.>; 发送时间: 2021年8月11日(星期三) 晚上6:35 @.>; @.@.>; 主题: Re: [dyweb/papers-notebook] Catalyzer: Sub-millisecond Startup for Serverless Computing with Initialization-less Booting (#237)
作者是 https://github.com/Ddnirvana，你要不直接问他
cc @Ddnirvana
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.
