Heracles: Improving Resource Efficiency at Scale

CFS调度器是有缺陷的，可能会导致SLO被频繁打破，具体可以看论文 Reconciling High Server Utilization and Sub-millisecond Quality-of-Service
实时调度算法（例如FIFO）可能会导致更低的利用率
开启超线程的话情况更复杂一点，相当于LC和BE同时运行在一个物理核心上，会有LLC，内存带宽，TLB等影响

有很多研究可以表明，LLC干扰对混部是有影响的，例如：

Quasar: Resource-Efficient and QoS-Aware Cluster Management
Cuanta: quantifying effects of shared on-chip resource interference for consolidated virtual machines
Reconciling High Server Utilization and Sub-millisecond Quality-of-Service
Increasing Utilization in Modern Warehouse-Scale Computers Using Bubble-Up
Scalable and Efficient Fine-Grained Cache Partitioning with Vantage

为了解决这个问题，Intel提出了CAT技术，用来隔离L3 cache

隔离LLC的方法有：

硬件技术
1. A Hardware Evaluation of Cache Partitioning to Improve Utilization and Energy-efficiency While Preserving Responsiveness
2. QoS Policies and Architecture for Cache/Memory in CMP Platforms
3. A low-overhead, highperformance,runtime mechanism to partition shared caches.
软件技术
1. Gaining insights into multicore cache partitioning: Bridging the gap between simulation and real systems
2. Q-Clouds: Managing Performance Interference Effects for QoS-Aware Clouds

2.2. 内存带宽

除此之外，大部分LC服务操作的数据集都比较大，CPU cache是肯定放不下的，所以，通常情况下会频繁的访问内存，因此，DRAM带宽不足也是造成违反SLO的问题之一

目前内存带宽的隔离，目前有很多相关的研究：

QoS Policies and Architecture for Cache/Memory in CMP Platforms
A QoS-aware Memory Controller for Dynamically Balancing GPU and CPU Bandwidth Use in an MPSoC.
Reducing Memory Interference in Multicore Systems via Application-aware Memory Channel Partitioning.
Fair Queuing Memory Systems

但是商用芯片上目前还没有硬件级别的隔离机制

在一些多socket服务器上，可以通过 NUMA channels 隔离工作负载

A Case for NUMA-aware Contention Management on Multicore Systems
The impact of memory subsystem resource sharing on datacenter applications

但是这些方法比较受限，由于numa架构的特点，它限制了DRAM的分配以及寻址

没有硬件级别的DRAM带宽隔离支持，使得动态管理混部负载变得更棘手

2.3. 网络带宽

在大型数据中心里，网络拥塞是很常见的，常见的一些解决网络拥塞的方法有

支持优先级的网络协议，用以区分LC网络数据包和BE网络数据包，例如：

Data Center TCP
Better Never Than Late: Meeting Deadlines in Datacenter Networks

同一个server内，入口网络和出口网络都可能拥塞

对于流出网络，可以通过tc或者我厂自己搞的tcp_throt来限制
对于入口网络，我们可以通过降低其cpu利用率来变相达到限制入口流量的目的，其原理基本就是：限制cpu利用率 -> 网络数据包中断变慢 -> 处理不过来 -> 丢包 -> 触发tcp拥塞控制算法
1. Solving the TCP-Incast Problem with Application-Level Scheduling.
2. 我厂更牛逼一点，tcp_throt直接丢包，直接触发tcp拥塞控制算法

由于LC服务的负载特点，网络带宽我们必须要能够实现动态调整，同时静态的网络优先级，可能导致利用率不高甚至饿死的情况出现，例如论文：Starvation prevention and quality of service in wireless LANs.

2.4. SSD设备

Hydra: A Block-Mapped Parallel Flash Memory Solid-State Disk Architecture

2.5. 功耗

功耗是另外一个混部可能出现干扰的资源之一。基本所有现代的cpu都支持超频技术，例如Intel芯片的Turbo boost技术，AMD芯片的Turbo Core技术

但是CPU是有热功耗设计的，如果CPU过热，bios主板会自动将CPU自动降频，因此，会影响LC服务的时延，通常来说，这种干扰可以通过前面我们讲过的DVFS动态调频技术来减缓注：我厂动态调频相关的几个模块都是关闭的，包括内核的cpufreq【使用性能模式】、intel专用的idle，所以理论上不会自动降频，但是发热超过TDP时，主板也是有可能会将CPU频率降低的

2.6. 多重干扰

一个更严重的问题是，一个BE作业可能产生上述所有资源维度的干扰，类似地，一个LC服务可能不仅仅是LLC敏感的，也可能是多种维度资源敏感的，例如对内存带宽也很敏感，对网络也很敏感，任何一种资源的延迟都可能导致SLO下降

因此，我们不能仅仅只隔离一种维度的资源，实际上，任何我们能想到的能造成干扰的资源都应该尽可能的监控并且隔离开来

另外，不同资源之前的干扰可能会互相影响，例如LLC不足可能实际上是内存带宽不足引起的，又例如，BE流量太大触发网络拥堵可能引起LC服务的CPU利用率下降

所以，理论上来看，种种干扰结合在一起，这是一个笛卡尔乘积，分析干扰问题变得非常复杂

3. 干扰表征 & 分析

表征（英语：characterization）一词为化学及材料科学术语，指用物理或化学方法对物质进行化学性质的分析、测试或鉴定，并阐明物质的化学特性

3.1. Latency-critical Workloads

以三个Google产品为例

第一个是websearch，特点：

高吞吐，低时延，严格SLO：99分位时延低于10毫秒
fan-out架构，一个请求会涉及上千个叶子节点
资源占用特点：
1. 高内存占用
2. 占用一定的内存带宽（40%内存带宽 ≈ 100%负载）
3. 计算敏感型，需要算分和排序
4. 网络带宽消耗小

第二个是ml_cluster，一个实时的文本聚类服务，聚类依赖的模型是离线训练出来的，并且会常驻在内存里【保证性能】

特点：

SLO：95分位时延不超过10毫秒
资源占用特点：
1. 相对于websearch，ml_cluster会占用更高的内存带宽，100%峰值负载是内存带宽占比60%
2. 非计算密集型的，CPU利用率较低
3. 网络带宽消耗小

一个有趣的现象是，ml_cluster每个请求都会用一点cache，会造成频繁的cache miss问题，所以它的负载和DRAM带宽是成线性关系的
第三个是memkeyval，一个类似于memcached的服务

相对于websearch来说，memkeyval绝大部分请求都是不需要怎么处理的，所以它可以有非常高的吞吐，并且时延非常低

特点：

99分位时延不超过100微秒
CPU密集型
内存带宽消耗小
网络带宽敏感

3.2. 表征方法

分别将上述三种类型的服务，和一个干扰程序跑在一个机器上，干扰程序会对各种维度的资源产生干扰，虽然这些都是单个节点的实验，但是由于负载是远程生成的，所以仍然有大量的网络流量然后观察在不同的负载点，干扰对LC长尾时延所产生的影响
测试环境：

Intel Xeons Haswell architecture，2.3GHz，2.5MB LLC
每个物理CPU包含N个核心
支持Intel的CAT技术

HyperThread：之前我们知道，LC服务和BE作业同时跑在一个逻辑核上，会导致严重的时延，所以，在这个测试里，我们将两个服务运行早同一个物理核上的不同HyperThread上，理论上来看，负载越高，对资源的争抢约严重，如果实验结果出现严重的长尾时延，那么我们就认为，通过HyperThread的方式让LC和BE共享物理核也是不靠谱的LLC：假设一个物理封装有N个逻辑核，在任意LC负载情况下，将LC绑定到足够的逻辑核上，直到能满足SLO，然后，将一个干扰程序绑定到剩余的逻辑核上，干扰程序会产生大量的cache miss，理论上来说，cache miss会对LC时延产生影响DRAM bandwidth：DRAM bandwidth的测试和LLC非常类似，我们通过numactl将干扰程序和LC程序放到同一个socket上，然后给所有的内存channel加上压力Network traffic：干扰程序跑在一个核上，其余的核都给LC程序，干扰程序会产生大量的低优出口带宽，然后通过TCP拥塞控制算法，达到流控的目的，预期LC的流量不受影响

Flow Rate Fairness: Dismantling a Religion

Power：因此，这里的测试目的，是验证CPU主频对LC时延的影响。和LLC以及DRAM的测试方法一样，只不过跑的是一个power virus程序，这个程序会对整个cpu所有部件产生压力，触发cpu自动降频，通常来说，Power敏感的都是一些计算密集型程序，The power virus is designed such that it stresses all the components of the core, leading to high power draw and lower CPU core frequenciesOS Isolation：为了完整性，测试一个综合性程序，测试假设在没有上述任何隔离的情况下，只依赖内核的cfs调度策略，将LC和BE运行在同一个机器的两个Container里，BE用google的brain程序

3.3. 干扰分析

实验结果如下，每一行代表一种干扰类型，每一列对应特定的LC负载，交叉汇聚点，就是在混部 + 特定LC负载时的时延【做了归一化处理，相对非混部场景下 + 特定负载时的时延】也就是说，如果时延 < 100%，则认为这种影响是可接受的，否则就是不可接受的

从上图来看，最明显的，brain，在只有cpu.shares没有任何其他隔离的情况下，混部对在线服务的影响是极大的一方面，最主要的原因在于内核可能将LC和BE同时运行在同一个core、甚至是一个HT线程上运行，这种问题可以靠像Paragon、Bubble-Up等这种系统来解决但是，很多时候，仅仅隔离多个核心是不够的，例如，从上图我们可以看出来

memkeyval是网络带宽敏感型的，但是websearch和ml_cluster不是
websearch对LLC(small)和LLC(med)型干扰是不敏感的，但是memkeyval和m1_cluster不是
还有就是，不同负载的情况下，干扰的结果也是不一样的，例如对ml_cluster来说，负载低于50%时，LLC(med)型的干扰是可以接受的，但是负载一旦超过50%，干扰的影响就变得非常大

所以，不管从哪个角度来看，我们都需要有一个动态的隔离管理系统来应对不同的负载以及不同类型的服务websearch：

LLC & DRAM 敏感：从上图来看，websearch对LLC(small)和LLC(med)干扰没什么感觉，但是LLC(big)就影响很大，主要有两个原因
1. 由于LLC是芯片内置的高速缓存，如果LLC被严重干扰，那么会导致频繁的指令集miss
2. 同样，第一个问题，会对DRAM带宽产生极大的压力
3. 随着负载的提升，情况有所好转，原因是因为websearch使用了更多的cores，干扰程序用的cores变少了
HyperThread部分敏感：从图上看来，只有当负载 > 80%的时候才出现一定的时延，主要原因是spinloop只会访问寄存器，不会使用L1,L2缓存，虽然hyperthread对websearch的影响很小，但是如果和其他干扰源结合在一起，影响可能会放大
Power不敏感：只有在最低负载的时候，时延有一定的影响，原因可能是power virus程序占用了太多的cpu资源
网络带宽不敏感

ml_cluster

LLC敏感：ml_cluster相对websearch，对LLC更敏感，主要原因是ml_cluster有大量的小请求，另外在50%~80%的负载之间，时延有严重的退化
DRAM bandwidth不敏感：看起来没什么影响
HyperThread不敏感：只有在高负载的时候才出现一定的时延
Power不敏感
网络带宽不敏感

memkeyval：由于memkeyval有非常严格的SLO，所以几乎对所有维度的资源都敏感

LLC：即使很小的LLC干扰，都会造成memkeyval时延抖动，原因是memkeyval每个请求都很小，会占用大部分的LLC。另外有个地方特助注意的是，LLC(med)干扰的时候，出现两个峰值
1. 一个是出现在最开始的时候，指令缓存被频繁换出，随着负载增高，获得的cpu越多，开始减缓
2. xx
DRAM：虽然memkeyval不怎么使用内存带宽，但是它对DRAM带宽是非常敏感的
HyperThread：不敏感，只有在高负载的时候才出现一定的影响
Power敏感：计算敏感型
网络带宽敏感：因为memkeyval需要消耗大量的网络带宽

4. Heracles Design

从测试结果上来看：

共享资源要隔离，否则对性能影响很大，例如DRAM bandwidth，LLC，Power，Network等等
LC服务在不同负载的情况下，对共享资源的需求是不一样的，需要有一个动态可弹性伸缩的机制，来保证LC所需要的资源随时都能满足

需要特别说明的是，Heracles是为 One LC + many BE tasks 而设计的，而不是为 many LC 而设计的Heracles的设计目标，在满足LC’s SLO的同时，尽可能的提高机器的资源利用率。所以Heracles并不完全反对完全干扰，它是可以允许一定的干扰存在，只要不违反SLO的情况下，就尽可能的调度更多的BE tasks上来

4.1. 隔离机制

Heracles使用4种隔离机制来减缓干扰

Core Isolation：使用cpuset来隔离，LC和BE分别隔离在不同的core上

core越多，隔离的粒度就越细越精确
动态调整
动态调整的生效时间取决于linux内核迁移task的速度，一般情况下是10ms左右

笔者注：cpuset的粒度是processor的，绑核的时候需要注意processor与core的对应关系，因为，processor的逻辑ID并非在cores上是连续的LLC Isolation：使用Intel haswall架构处理器提供的CAT技术来做隔离关于CAT技术，可以关注我们之前的调研：http://wiki.baidu.com/pages/viewpage.action?pageId=328312192方法是：

划分两个LLC partition，一个是给LC用，一个是给BE用
通过修改MSR寄存器，动态调整LC与BE的LLC partition
生效时间大概几毫秒

笔者注：目前公司2016年H2新到货的机器，基本上都是v4以上，支持CAT、MBM等相关技术DRAM隔离：目前硬件上不支持DRAM相关的隔离，Heracles的方法是，通过监控 + 减少cores来达到降低DRAM技术的技巧笔者注：MBM等相关技术，和CAT类似，也是Intel 新架构才支持的，MBM技术可以监控内存带宽的使用，通过perf查询Power isolation：暂不讨论Network traffic Isolation：使用tc来做流控

划分两个partition，使用一个qdisc，限制BE作业的总出口带宽，LC的带宽不限
生效时间百毫秒

笔者注：tc是不支持入口流控的，也就是说，不能限制别人给你发数据包的速度，例如无法限制下载速度
我厂对网络带宽流控方面既支持tc，但是也有我们自己研发的tcp_throt
tc和tcp_throt流控的原理都是一样的，丢包

4.2. 整体架构

Heracles会实时监控LC的latency当Latency比较小时，这个时候是可以混部更多的BE的当Latency比较大时，应该限制BE的资源占用以避免干扰另外，Heracles还会监控load，当load太高时，禁止混部下面是整体架构，Heracles会在每个机器上都会部署一个Agent程序，包含1个总控controller + 3个子controller，每个controller分别负责单独某一维度的资源控制

4.3. 控制器

总控：top-level controller伪代码流程如下

每隔15s查询一次LC的长尾时延（tail latency）以及负载Load计算slack总控的处理分5档：

当slack < 0时：已打破SLO，立即关闭BE，并且EnterCooldown()【突发尖峰】
当slack > 0 && load > 0.85时：即将打破SLO，关闭BE
当slack > 0 && load < 0.8时：打开BE
当slack < 0.1时：不允许继续混部BE，但已有的BE可以继续运行
当slack < 0.05时：减少绑核【万能药膏，虽然不是特别精确，但是确实可以降低任何其他唯独的资源的占用】

如果slack超过10%时，子控制器会受到总控的指令，允许BE任务获得更大的系统资源，当然前提是它的资源没有饱和，其中每个子控制器都是独立决策的
Core & Memory控制器
管理LLC，DRAM bandwidth，cores，因为这几个资源都是非常密切相关的
它的伪代码逻辑如下

从伪代码上来看，这个控制器，只调整LLC & Cores，所以这个控制器有两个状态：

GROW_LLC
GROW_CORES

初始状态是：GROW_LLC，如果GROW_LLC失败，转向GROW_CORESDRAM bandwidth由于目前没有隔离机制，只能通过调整Cores & LLC来达到相似的效果，所以这里两个状态都会先看DRAM bandwidth超限了没有
另外它这里还有一个PredictedTotalBW()，用来预测DRAM bandwidth是否会超限
猜测：bw_derivative没理解，应该是加了个类似Buffer机制？
基本流程如下：

先检查DRAM bandwidth是否超限，如果超限了，直接减少绑核，减多少，看BeBwPerCore()
1. 绑核是万能膏，只要没cpu了，DRAM bandwidth和LLC的占用都会下降
如果DRAM bandwidth没超，则进入GROW_LLC和GROW_CORES状态，动态调整BE的资源限额
1. GROW_LLC状态：
  1. 如果PredictedTotalBW()会超限，则不允许调整，PredictedTotalBW()就是预测DRAM bandwidth是否会超，如果逾期会超，就不增加LLC了。转向调整GROW_CORES
  2. 否则就增加LLC，增加LLC后重新评估DRAM bandwidth占用，其中bw_derivative 和语义不明确
    1. 猜测：BeBenefit()作用是评估继续增加LLC是否对BE产生收益，原理应该很简单：一个是，绑核的粒度会比LLC细，因为LLC是共享的，也就是说，分配了LLC但是没有足够的Cores，BE也用不起来；另一个就是，分配了LLC，但是没用满，再增加也没用
2. GROW_CORES状态：
  1. 评估增加一个CORE之后的DRAM bandwidth是否会超限，如果超了，不允许增加CORE，转向GROW_LLC状态
  2. 否则就增加1个CORE，状态保持不变

所以整个过程看起来，就是增加LLC和Cores，先加LLC，再加Cores，初始情况下，每个BE作业，分配1一个core和10%的LLC
不管是加LLC还是Cores，只要一旦DRAM bandwidth超了，立即回滚

Power控制器
伪代码逻辑如下：

Heracles使用RAPL来测定CPU的实际功率、最大设计功率，并监控LC程序所在的Core的频率
如果实际功率 > 0.9 TDP，并且LC所在核心的频率很低，则减少BE的绑核如果实际功率 < 0.9 TDP，并且LC所在核心的频率有保证，则增加BE的绑核
网络带宽控制器伪代码逻辑如下：

BE的带宽限额，是整机 – 在线 – 一定的Buffer

5 效果评估

5.1 方法

两个过程：

单节点评估
小集群评估：约10台机器

程序：

websearch/ml_cluster/memkeyval
N个干扰程序
1. stream-LLC/stream-DRAM：前者流式访问一个LLC一半大小的数组，后者访问一个比LLC还大的超大数组，验证在不影响SLO的前提下，Heracles能极大提高LLC利用率
2. cpu pwr：验证Heracles能够自动均衡LC核和BE核之间的功率，保证LC有足够的频率
3. iperf：验证Heracles能够自动限制BE的带宽，不影响LC
4. brain：基于机器学习的图片自动打标，计算敏感型，会吃比较多的LLC和DRAM
5. streetview：google地图的全景图生成器，非常依赖DRAM

对于LC程序而言，我们更关注的是SLO Latency，但是需要注意的是，这里我们只关注长尾，也就是最差的值，例如99分为最大的时延是否打破SLO，等等对于BE，我们更关注的是它的吞吐并定义：Effective Machine Utilization (EMU) = LC Throughput + BE Throughput
注意：作者这里是使用了一个归一化的衡量方法

假设这个机器只跑LC，得到在不违反SLO情况下的最大负载，也就是peek load；假设这个机器只跑BE，得到最大的peek load
混部情况下，LC Throughput是指当前的实际负载相对peek load的比率，同理， BE Throughput也是
在资源合理充分利用的情况下，EMU是可以大于1的

5.2 单节点测试结果

SLO：

从实际测试结果来看：

不管是websearch、ml_cluster还是memkeyval，Latency确实变小了，但并没有打破SLO，前者减少了40%~20%，后者80%~40%
在所有组合的场景下，EMU都得到了极大的提升

再来看下各个维度的资源利用率如无特殊说明，图示曲线一律如下对应

并且横坐标都是负载，纵坐标是资源占用率【total是系统】websearch：

websearch是（LLC+DRAM bandwidth敏感，Power部分敏感，HT不敏感，带宽不敏感）

websearch + stream-LLC：stream-LLC只会产生一半的LLC，对DRAM并没多大压力，所以最终的结果是，CPU利用率上去了，CPU power上去了，但是DRAM使用很低
websearch + stream-DRAM：stream-DRAM会产生大量的DRAM bandwidth，但是Heracles会通过减少绑核来限制它对DRAM bandwdith的占用。所以最终结果来看，就是DRAM bandwidth使用是很满的，但是CPU利用率很低，CPU Power也不高
websearch + brain：brain会吃比较多的LLC+DRAM bandwidth，所以看起来，整机DRAM bandwidth占用会比较高，CPU比较高，CPU power也会更高一点
websearch + cpu_pwr：cpu_pwr会吃比较多的CPU，但是不占用DRAM bandwidth，所以，整体看起来，是CPU和CPU Power占用很高，但是DRAM bandwidth占用很低
websearch + streamview：强依赖DRAM bandwidth，所以会看到DRAM bandwidth占用是最高的，但是CPU利用率会比较低，CPU Power也不算高

memkeyval：

memkeyval是（LLC+DRAM bandwidth极度敏感，Power敏感，HT不敏感，带宽敏感）

+ stream-LLC：我们知道memkeyval是对LLC非常敏感的，任意的LLC干扰都可能会造成memkeyval时延抖动，但是实际上，只要隔离得好，就不会有影响，还能提高资源利用率
+ stream-DRAM：同上，虽然memkeyval使用很少的DRAM bandwidth，但是对DRAM bandwidth仍然是非常敏感的。不过只要隔离开，不相互影响，就没有问题

其他的同websearch，没什么好说的

5.3 集群测试结果

集群测试是以websearch为例，fan-out架构，root结点接受请求，并向所有叶子结点发起查询，并聚合查询结构、排序，最终返回给用户时延一律取30秒内的平均时延【单节点测试的时候，关注的是长尾时延】SLO是：99分位平均时延不能超过非混部 + 90%负载时的平均时延【都是30s】10台机器中，一半跑brain程序，另一半跑streetviewSLO和EMU：

Latency升高了20%左右，EMU提升了20%~60%，并且EMU保持在最低80%，平均90%因此，总的来看，Heracles是能极大提升机器资源利用率的

6 其他相关的一些东西

隔离机制：

cache隔离：目前Heracles使用的是基于Intel CAT的 coarse-grained, way-partitioning 的Cache隔离机制
1. replacement policies：
  1. A Comparison of Capacity Management Schemes for Shared CMP Caches
  2. PIPP: Promotion/Insertion Pseudo-partitioning of Multi-core Shared Caches
2. way-partitioning：
  1. Utility-based cache partitioning: A low overhead, highperformance, runtime mechanism to partition shared caches
  2. Reconfigurable Caches and Their Application to Media Processing.
3. fine-grained partitioning：
  1. Probabilistic Shared Cache Management (PriSM).
  2. Scalable and Efficient Fine-Grained Cache Partitioning
4. soft policies：通过一些特殊的QoS策略，来模拟共享cache + 内存的隔离
  1. From Chaos to QoS: Case Studies in CMP Resource Management
  2. A Framework for Providing Quality of Service in Chip Multi-Processors
  3. Communist, Utilitarian, and Capitalist Cache Policies on CMPs: Caches As a Shared Resource
  4. CQoS: A Framework for Enabling QoS in Shared Caches of CMP Platforms
  5. QoS Policies and Architecture for Cache/Memory in CMP Platforms
磁盘IO隔离
1. SATA
  1. the cgroups blkio controller
  2. native command queuing (NCQ) priorities，INTEL CORPORATION. Serial ATA II Native Command Queuing Overview.http://download.intel.com/support/chipsets/imsm/sb/sata2_ncq_overview.pdf
  3. prioritization in file-system queues
  4. partitioning LC and BE to different disks
  5. replicating LC data across multiple disks that allows selecting the disk/reply that responds first or has lower load
2. SSD
  1. many SSDs support channel partitions, separate queueing, and prioritization at the queue level
  2. support suspending operations to allow LC requests to overtake BE requests

Interference-aware cluster management：通过调度来提前避免干扰的问题

Q-Clouds: Managing Performance Interference Effects for QoS-Aware Clouds：通过调整资源分配，以减少对混部的vm的干扰
Bubble-flux：通过监控内存压力，避免将LC服务调度到压力大的机器上
1. Directly characterizing cross core interference through contention synthesis
2. Bubble-flux: Precise Online QoS Management for Increased Utilization in Warehouse Scale Computers
CPI2
Paragon: QoS-Aware Scheduling for Heterogeneous Datacenters.
Quasar: Resource-Efficient and QoS-Aware Cluster Management

LC之间的混部

energy proportionality
1. Tradeoffs between Power Management and Tail Latency in Warehouse-Scale Applications
2. Runtime Joint Speed Scaling and Sleep States Management for Power Efficient Data Centers
3. Towards energy proportionality for large-scale latency-critical workloads
4. PowerNap: Eliminating Server Idle Power.
5. Power Management of Online Data-Intensive Services
networking performance
1. IX: A Protected Dataplane Operating System for High Throughput and Low Latency
2. Chronos: Predictable Low Latency for Data Center Applications
hardware-acceleration
1. Thin Servers with Smart Pipes: Designing SoC Accelerators for Memcached
2. A Reconfigurable Fabric for Accelerating Largescale Datacenter Services.
3. High Performance Hardware-Accelerated Flash Key-Value Store.

成功，源于对美学的执著追求

Heracles: Improving Resource Efficiency at Scale

1. 简介