本文主要对warm instance进行优化。实际上，warm instance对CPU来说是cold的。因为warm instance是来了包才真正执行，对一台机器上的很多个warm instance来说，它们是交替执行的。同时执行的时间一般是几毫秒。文章指出，warm instance性能损失的最大来源（平均56%）是在CPU front-end，特别是指令的on-chip misses

文章提出了一个record-and-replay instruction prefetcher。

workload开源 https://github.com/ease-lab/vSwarm

background

background总结的不错，主要包括serverless的四个特点

执行时间短
对短函数的需求持续增加
内存占用少
到达时间在1秒到几分钟内

warm function的交替执行导致性能下降的主要原因是front-end的性能下降。 front-end的性能下降的主要原因是频繁的L2和LLC指令缺失。这种on-chip miss rates可被解释为单次调用的large instruction footprints，一般在300KB-over 800KB。

此外，同一函数的不同调用的指令足迹存在高度的共同性。

design

Jukebox最大的不同是fetch到L2上，这么做是出于两点考虑：

L1太小
预取到L2简化了一些设计

Record

总体来说，是一个FIFO的记录L2 miss的过程。

Replay

Jukebox的重放阶段是由操作系统在收到一个新的函数调用时触发的。预取引擎从元数据区域按照写入内存的相同顺序读取元数据。

元数据条目被预取到预取逻辑内部的一个小FIFO中。一旦元数据条目从内存中返回，预取器将代码区域的基址传递给I-TLB2，像正常的代码请求一样触发地址转换。这有两个目的：首先，它确保Jukebox不依赖于物理地址，这些地址可能会因为正常的操作系统活动（如分页或内存压缩）而改变。其次，它有效地预先填充了TLB的代码页的翻译。一旦知道了代码区域的物理基址，利用条目访问向量的信息，预取引擎就会重建代码区域内每个被访问的缓存行的完整地址，并将它们排入L2预取队列。