1. INTRODUCTION

核心前提：只要独占 cache size 足够大，业务的性能是可以得到保证的
we can conclude that whether CAT can provide perfor mance isolation between workloads is highly dependent on the size of the dedicated cache

思路：基于CPI的动态反馈，来动态调整每个容器的独占 cache 和共享 cache 容量，达到每个容器都可以得到很好的性能

难点：预测 wss（业务真正需要的cache size）。这里面有一个容量失效和冲突失效的问题，冲突失效和容量失效是 有一定的overlap的，冲突失效是因为多条cache数据映射到同一个cache line上，导致的miss，这个问题会导致wss难以预估。这个问题没有什么太好的思路，所以dCat的思路是基于feedback来动态扩大cache size

dCat 的状态机是这样的：
简单来说，是一个实时feedback的过程
Reclaim：初始状态
Recevier：减少cache退化，增加cache会提升
keeper：减少cache退化，增加cache不提升
Donor：减少cache不退化，增加cache不提升
Streaming：增加cache不断提升

系统流程：

备注：

1. baseline是基准性能，但是每个阶段，都有不同的 baseline，会动态变化 Baseline performance is only defined for a specifi workload phase, so it has to be determined again at every phase change.
2. Categonize workloads，就是识别容器的状态，对应到上面的几个状态机上，Reciver、keeper、Doner

问题：

1. 论文中CAT隔离，使用的是qpos，qpos是CAT的前身，只支持core级别的cache隔离，也就是cache隔离相当于是通过绑核实现的

论文重点

1 introduction

autopilot 算是 google 今年混部领域最重磅的论文了吧

论文原址：https://dl.acm.org/doi/pdf/10.1145/3342195.3387524

在传统的数据中心里，资源超售最简单的方式就是把闲置资源回收再分配，total = total – allocated + reclaim

有时候，业务为了应对峰值流量（特别是互联网服务这种有明显流量特征的），都会购买多一些冗余资源。但是这些冗余资源会因为各种原因，不是那么准确。比如流量随着时间流逝会逐渐发生变化、或者用户过于焦虑

用户填的Quota永远都是不准的

这会带来一些问题：

1. 集群资源浪费，由于Quota不准，导致机器资源被大量闲置和浪费。比如 Quota 分配出去了100c，但实际使用了10c
2. 集群负载不均衡，同样两个机器，分配率一样，但是实际使用差别很大，对混部性能的影响就不一样

为了解决这个问题，google设计了autopilot，尝试通过自动的校准用户的 Quota，实现一定程度的超售，降低成本

论文原址：https://www.usenix.org/system/files/conference/atc18/atc18-iorgulescu.pdf

演讲PPT：https://www.usenix.org/sites/default/files/conference/protected-files/atc18_slides_iorgulescu.pdf

这是微软在18年 usenix 会议上公开的一篇混部论文。这也是微软在混部这个领域公开的为数不多的论文之一。论文中描述了bing业务（非公有云）如何通过在离线混部 + CPU Blind Isolation 这个技术，将 indexserver 集群的利用率从21%提升到66%的过程

其中最关键的，还是 CPU Blind Isolation 这个技术，很有意思。

这是google在13年发表的一片论文：https://dl.acm.org/doi/10.1145/2465351.2465388

这篇论文里，最有价值的地方在于建立了一个对业务透明，能够实时感知在线业务运行质量，并且能自动优化的机制

基本概念

• CPI：uses cycles-per-instruction，平均每条指令消耗的时钟周期（时间），相当于指令执行的代价。

现代处理器均有多级缓存，类似下面这样的一条指令：“ mov 0x200160(%rip),%rax ”，其执行时间由缓存是否命中决定（L0/L1/L2）。

这是一篇非常经典的，混部领域解决延迟敏感问题的论文，作者当年还只是mit的一名博士生，在google实习，heracles 是这个学生毕业论文里的其中一部分

论文原址：https://dl.acm.org/doi/pdf/10.1145/2749469.2749475

这是一个实时的、自反馈的，大规模提升资源利用率的系统

1. 简介

为了解决LC服务和BE作业混部引起的LC服务SLO下降的问题，我们开发了Heracles，一个实时的控制器，能够动态使用硬件隔离机制和软隔离机制，保证共享资源的干扰问题

Heracles能够在保证LC服务足够SLO的情况下，最大限度的将空闲资源用来运行BE作业，同时，结合实时监控和离线分析，自动检测干扰源，并在合适的时机，自动调整隔离机制防御干扰产生

在这里我们分两步走：

第一步，我们首先来研究一些经典案例，最终会抛出一个结论，那就是混部情况下【如无特殊说明，以下混部一律特指LC服务和BE作业】，干扰绝大部分情况下都是不均匀的、但是和负载有较强的相关性，所以，通过静态分区的方式来隔离共享资源是不够的

第二步，然后我们会解释为什么要设计Heracles，并且会证明

1. 多种隔离机制的互相结合，是实现高利用率并且不打破LC服务SLO的关键所在
2. 将干扰问题细分成几个独立的子问题，能够大大的降低动态控制的复杂性
3. 为什么一个运行在所有机器上的、实时的监控程序是必须的

第三步，我们来评估一下Heracles在Google内部生产环境能产生多大的收益，测试表明，能够将机器利用率提高到90%左右

最后，我们通过硬件的一些机制来实现DRAM带宽的监控与隔离，进一步提高Heracles的精确性以及降低对离线分析的依赖

论文原址： http://csl.stanford.edu/~christos/publications/2014.mutilate.eurosys.pdf

In this paper, we analyze the challenges of maintaining high QoS for low-latency workloads when sharing servers with other workloads.

The additional workloads can interfere with resources such as processing cores, cache space, memory or I/O bandwidth

The goal of this work is to investigate if workload colocation and good quality-of-service for latency-critical services are fundamentally incompatible in modern systems, or if instead we can reconcile the two

1. Introduction

google服务器集群的管理系统，类似于百度的Matrix，阿里的fuxi，腾讯的台风平台等等，还有开源的mesos

Borg provides three main benefits: it

1. hides the details of resource management and failure handling so its users can focus on application development instead;
2. operates with very high reliability and availability, and supports applications that do the same; and
3. lets us run workloads across tens of thousands of machines effectively.