workload白天和晚上不一样，不同的日子也不一样（例如双十一）
因为没有办法对workload估计得很准，云系统用户总是申请比所需要的多的资源，这些“slack”是一种浪费
Autopilot目标：减少slack的同时最小化OOM
Autopilot操作：调整并行任务数，调整单个任务的资源使用量
scaling分为水平scaling和垂直scaling，水平scaling是调整并行任务数，垂直scaling是调整单个任务的资源使用量，这篇文章主要讨论内存的垂直scaling
Preprocessing:
每秒记录一个usage数据点；
CPU per-task histogram: 一个向量，每个分量表示在这个time window内每个usage buckets的usage数据点数量；
memory per-task histogram: peak memory usage in a time window；
per-job histogram: sum over per-task histogram；
Moving window recommenders
希望需求上升时能很快上升，需求下降时能慢慢下降
提出了三种滑动窗口的方法，都比较保守，而且会在推荐值的基础上加一点余量
大概的思想是，不只根据数量去做平均，还要根据load的大小 (magnitude) 去做平均
max适合OOM最敏感的任务，Spj适合比较敏感的任务，Savg适合不敏感的任务
Recommenders based on machine learning
构造了一个损失函数包括过去采样的overrun，underrun，以及switching cost。
同时存在多个arg min的模型，它们的超参不一样，用的时候选择损失函数最小的。
这些模型是离线+A/B test调出来的，没有给具体方法，只有loss function。
horizontal
指定一个目标平均util，通过伸缩replica来维持这个值。
策略
实验结果是滑动窗口在减少OOM上更好，ML方法在减少slack上更好。
后面主要是讨论用户体验。
有一篇值得follow的工作：Hydra: a federated resource manager for data-center scale analytics，是微软的资源管理系统，在这篇论文之前。