入选高性能计算著名顶会SC20长论文！详解阿里“Alita”
作者：薛帅 赵尚 宋卓 陈善佩 吴一昊 徐宇
背景
阿里云操作系统团队与上海交通大学新兴并行计算研究中心一起合作的论文 “Alita: Comprehensive Performance Isolation through Bias Resource Management” 被系统领域著名会议 The International Conference for High Performance Computing, Networking, Storage, and Analysis (SC20) 录用为长论文。SC 由 ACM和IEEE计算机协会创立于1988年，是高性能计算领域的最重要会议 （CCF A），本届会议已经于 2020.11 月在线上召开。
论文作者：陈全，薛帅（花名：咸正)，赵尚（花名：笑意)，陈善佩（花名：雏雁），吴一昊（花名：丁缓），徐宇（花名：弃余），宋卓（花名：文侑），马涛（花名：伯瑜），杨勇（花名：智彻），过敏意。
我们的工作有效解决了在大规模公共云业务上遇到的基于 split-lock 和 LLC 竞争引起的性能干扰和性能下降问题，包括基于性能的攻击等，并一举消除了此前由于此类竞争引起的性能抖动，同时进一步提高了综合资源利用率。
摘要
公有云平台的租户在同一节点上共享硬件资源，导致潜在的性能干扰（或恶意攻击）。一个租户如果过度使用总线（Bus）、最后一级缓存（LLC）/内存带宽和功耗，同一节点上邻居的性能会显著降低。为了消除这种不公平现象，我们提出了Alita，一个由在线干扰识别器和自适应干扰消除器组成的运行时系统。干扰识别器通过监控硬件和系统级事件，识别资源污染者。消除器只对污染者的资源使用进行节流，从而提高正常应用的性能。具体来说，Alita采用总线锁稀疏化、偏置LLC/带宽隔离和选择性功耗节流来限制污染者的资源使用。实验和公有云（3万个节点）的结果表明，基于系统级信息，Alita显著提高了多租户虚拟机的性能。
Section I. 介绍
公有云通过虚拟化技术将一台宿主机（host）抽象为多台虚拟机 (VM) 交付给客户，多个虚拟机之间共享计算、IO和网络等资源，大大提高了资源利用率。当机器整体负载高时，常常出现共享资源竞争。
图1展示了云平台中多个虚拟机共享同一个节点的场景。CPU和内存可以显式分配给不同VM，但由于共享资源的竞争，VM可能无法达到预期的性能。在图1中，多个虚拟机共享同一节点上的总线、最后一级缓存(LLC)/内存带宽和power。实验表明，如果存在资源竞争干扰，VM的性能会下降5倍以上。消除严重的资源竞争干扰对于实现服务水平协议(sla)至关重要。如果总线被逻辑核心
一般来说，可以通过显式的静态资源隔离来消除对资源的竞争。例如，LLC/内存带宽可以使用缓存分配技术(CAT)和内存带宽分配(MBA)进行限制，CPU粒度的功耗可以使用RAPL进行调整。然而，之前的文献表明，如果对资源的竞争只是轻微的，显式静态分配资源会导致整个系统性能不佳。此外，目前没有管理总线锁的接口。之前有很多关于管理内存带宽争用的研究，但之前的工作都没有考虑由总线锁引起的性能干扰。即使内存带宽没有饱和，长时间的总线锁也会显著降低同时运行的应用的性能。
在消除资源争用造成的性能干扰的同时，最大限度地提高整个系统的性能，存在三个方面的挑战。首先是在线识别资源争用只能基于底层信息。出于隐私考虑，租户通常不会暴露应用级信息。第二，对于无法隔离的资源（如总线锁），很难将干扰降到最低。第三，对于可以隔离的共享资源(如LLC和电源)，很难量化争用程度并适当分配资源。
在本文中，我们提出了 Alita，一个全方位的生产级运行时系统，可以有效地缓解性能干扰。Alita由在线干扰识别器和自适应干扰消除器组成。Alita部署在云中的每个节点上，管理每个节点的所有共享资源。具体来说，识别器监控每个核心上的底层性能事件（Split lock频率、LLC/内存带宽、温度等）。每核心事件信息聚合为VM级事件信息，以识别产生严重干扰的资源污染者。Alita只在争夺严重时限制资源污染者的资源使用。一旦识别出污染源，消除器就会对 split lock 进行稀疏化处理以消除对内存总线的争夺，执行偏置LLC隔离以消除对LLC/内存带宽的争夺，降低温度较高的内核的功率。
本文的主要贡献可以概括为以下几点：
全面调查各种类型的性能干扰。我们研究引入重大干扰的原因，这对如何消除这种干扰很有帮助。
操作系统级方法识别资源污染者并消除干扰。由于云厂商只能获得操作系统级信息，我们提出了不依赖应用级信息的操作系统级方法。
生产环境部署验证。我们在一个包含3万个节点和25万个虚拟机的生产环境中上部署了Alita。Alita上线两年，数据表明，Alita已经消除了租户的SLA干扰。
Section II. 性能干扰调研
为了对各种类型资源竞争的影响进行细粒度的探索，我们使用了三个程序来产生频繁的split lock、消耗过多的LLC空间和消耗过多的电力作为资源污染者（分别称为 "bus polluters"、"LLC polluters "和 "power polluters"）。我们使用Parsec和Tailbench中的工作负载作为典型benchmark。在每个测试中，我们在与普通虚拟机共处的虚拟机上部署了不同类型的资源污染器。我们使用执行时间（execution）作为Parsec的性能指标，使用响应延迟（responce latency）作为Tailbench的性能指标。
A. 内存总线锁竞争
我们在一个运行在几十万个节点上的应用程序中观察到了频繁的split lock。Algorithm 1时bus polluters的一个示例。对应于算法1，图2展示了一个 counter对象在缓存（cache）中的数据放置情况。可以看到，当数据是四个字节对齐时，变量c是横跨两条缓存行（cache line）存储的。
__sync_fetch_and_add(第6行)是一条原子指令，通过split lock来保证变量c的原子访问。两个缓存行中的c的全部值被访问之前，总线被始终被锁定。在这个总线锁期间，拒绝所有其他CPU或bus agent对总线的请求。如果c的一部分没有足够快地填入缓存行（例如，当必须从内存中读取数据时），该锁将长时间地阻止所有数据访问。通过运行Algorithm1，单核可以达到CPU的split lock频率峰值（260000 split lock/每秒）。
阻塞其他core对总线的访问，以及配置总线锁协议所需的开销，导致数据访问延迟明显增长。同时，split lock不仅会降低产生split lock核心上进程性能，还会降低其他所有核心上进程的性能。Lock add, lock btc, xchg, lsl, far call，ltr等指令都可能会导致split lock。
强制8字节对齐，迫使变量c存储在单一的缓存行中，可以消除Algorithm1中的split lock。现代编译器能够自动调整对齐参数，但总是强制执行8字节对齐（或更大）会浪费缓存空间。另外，开发者自定义对齐策略以节省LLC空间或实现其他设计目的，使得 split lock 仍然广泛存在于云中。实际应用中，开发者的代码难以保证（例如，设计不良的数据结构），开发者可能在不重新编译的情况下执行遗留的二进制代码。一些恶意开发者甚至会故意频繁地生成split lock进行性能攻击。
在我们研究的云中，很多应用都会产生split lock。split lock在3dsmax、Houdini、Maya、Blender}以及一些在线游戏服务中普遍存在。电影公司经常利用云上的3dsmax进行渲染，游戏公司使用云平台进行玩家同步。Linux中的Atomic Bitwise Operations也可以很容易地产生split lock。Figure 3展示了云中虚拟机的split lock频率的累积分布。该云有80个节点，主要托管一个在线游戏服务。可以看到，超过20%的4vCPU（虚拟核心）虚拟机，每秒产生超过10万次的split lock。
在我们的一个通用的、10000个节点的云平台中，每周会在大约2600个节点中检测到split lock。图4展示了在随机选择的10小时内，split lock频率的最大的500个节点的频率热力图。在图4中，由于Alita已经使能了split lock隔离，所以split lock频率小于每秒70000 split lock/s。由于租户的应用信息是保密的，我们没有列出会产生split lock的典型租户应用。图3和图4表明，内存总线锁争用在真实的生产型云平台中是普遍存在的。
图5展示了bench应用与算法1同时运行时的归一化执行时间(归一化到它们的单独执行时间)和整个节点的对应的内存带宽使用量(绿线)。在这个实验中，为了避免LLC竞争，两个虚拟机运行在不同的socket上。混跑的parsec应用的归一化执行时间提高了1.1到6.2倍。对于Tailbench中的xp和sh，由于内存总线锁争用，延迟增加了5000多倍。
此外，每次测试中基准应用和polluter使用的内存带宽和不到3GB/s（峰值带宽为160GB/s）。我们还将Intel mlc与polluter共同运行在同一节点上的不同的socket中，以测量内存延迟。图6展示了mlc的内存访问延迟。由于频繁出现的split lock，延迟从122 ns增加到962 ns。可见，性能下降是由split lock导致的访问延迟增加引起的，而不是带宽争用。
我们还用Algorithm 1和mlc在其他公有云（AWS，Google Cloud）进行了测试。结果表明，Algorithm1显著增加了内存访问延迟，也就是说，其他云没有隔离内存总线锁争用。
B. LLC/Bandwidth 竞争
我们使用Cachebench作为LLC polluter，它在短时间内大量占用缓存。图7展示了基准应用与LLC polluter同时运行时的归一化执行时间（归一化为其单独执行时间）。对于每个测试，我们都使用了在socket中具有四个vCPU的小型虚拟机。在此图中，"Default"代表LLC自由共享时的性能。"Static"代表LLC按照虚拟机的核数比例静态分配给虚拟机时的性能。polluter和基准应用程序各分配了4/24/*33= 5 MB的LLC空间（每个socket上有24个物理核心和33MB的LLC）。
如果没有LLC隔离(Default)，即使polluter只使用少量的CPU核心，基准应用程序的性能也会因LLC polluter干扰而显著下降。在最坏的情况下，执行时间会增加1.2倍。如果LLC是静态隔离的（Static），基准应用程序的性能并不是最佳的（例如，fs的归一化执行时间增加1.47倍）。如上图所示， bs、rt、 bt和x264对LLC不是特别敏感，因此它们的性能没有受到静态配置的严重影响。然而，fs对LLC很敏感，静态分配一个较小的LLC空间给 fs，它的性能就会显著下降。
C. Power竞争
由于硬件设计的固有限制，每当CPU的功耗达到其TDP时，所有核心的频率都会降低到相同的低频，也就是说，power polluter会降低其运行socket中所有核心的频率。
我们观察到，一个包含向量运算的程序（例如AVX指令）比只使用标量指令的程序消耗的功率要大得多。许多图形渲染应用和科学应用，如 Linpack，消耗了大量的功耗。Mprime通过让CPU重复计算快速傅里叶变换来给CPU施加压力，从而导致显著的功耗消耗。在本实验中，我们将Mprime作为power polluter。实验结果表明，当Mprime使用24个逻辑核心时，它的功耗可以达到一个CPU的TDP。
为了说明功耗争用的现象，我们在同一CPU上运行了Mprime和power polluter， 分别使用4个逻辑核心与使用24个逻辑核心。我们通过显式隔离消除了LLC/带宽争用的影响，并且在这个实验中没有发生 split lock。图8展示了基准应用与Mprime共处时的性能，并将其归一化为单独运行时的性能。基准应用的归一化执行时间在最差的情况下上升了1.4倍。
在设计Alita时，我们面临着三个关键的挑战，Alita是一个整体的运行时系统，它可以缓解混跑应用之间的各种类型的干扰。
挑战1：干扰应在事先不知情的情况下在线识别。干扰发生的时间间隔不固定。由于云厂商只能获得操作系统级的统计数据，需要建立一种机制，在事先不了解应用的情况下及时识别和缓解干扰。
挑战2：没有隔离内存总线的接口。虽然CPU在必要时保证了对多条缓存线的原子访问，但没有隔离不同虚拟机的总线锁的接口。因此，无法通过使用显式隔离来消除内存总线竞争。
挑战3：没有用于监控CPU核心功耗的接口。需要一个机制来识别高功耗的核心，以确定功耗污染者。然而，CPU和操作系统并没有提供每个核心的功耗监控。
Section III. Alita的机制
图9展示了Alita的架构，它由在线干扰识别器和t自适应干扰消除器组成。Alita作为守护进程运行在云平台的每个节点上，并记录每个虚拟机使用的CPU核心。
大多数现代处理器都有特殊的片上硬件，称为性能监控单元(PMU)。PMU可监控微架构事件，如经过的周期、缓存命中、缓存缺失等。为了实现在线干扰识别（挑战1），Alita利用基于PMU的监控和隔离技术，提供了较短的响应延迟（小于1毫秒）。通过PMU，可以准确找到所有的资源polluter。Alita的操作方法如下：
对于每个节点，Alita会定期收集每个CPU核心的PMU事件的统计数据，并将其聚合为虚拟机级别的统计数据。Alita根据这些统计数据，识别资源polluter。对于每个核心，收集到的事件包括占用的LLC的大小、split lock的数量和CPU核心的温度。我们根据核心的温度来识别power polluter（挑战3）。
为了缓解总线锁的竞争，Alita通过减慢相应CPU核心的频率，自适应地对bus polluter造成的split lock进行稀疏化处理（挑战2）。为了缓解LLC/带宽干扰，Alita隔离了LLC polluter，并允许普通虚拟机共享所有LLC空间，以提高整个系统的性能。为了缓解功率干扰，Alita限制power polluter的核心所使用的功率。这里的挑战在于，为资源polluter确定合适的资源配额。
Alita不需要应用级的信息，只依赖于低级的硬件统计信息。根据虚拟机的相对性能迁移虚拟机不在本工作范围内。Alita可以与其他云平台的虚拟机管理系统相结合，以平衡云平台中各节点的工作负载。
Alita通过限制资源污染者，以缓解其共同运行者的性能下降，这种解决方案在实践中是合理的。为了处理bus polluters，最新的Linux内核（5.7版本）引入了一个检测和处理split lock的补丁。在这个补丁中，内核检测到split lock会发出一个SIGBUS信号，直接杀掉造成split lock的用户进程。相比之下，Alita仍然允许这类进程在性能降低的情况下运行。
我们还联系并协助长期运行bus polluters的所有者解决异常频繁的split lock。对于LLC polluters来说，其LLC区域的大小是根据其虚拟机的核心数量来确定的，从资源的角度来看，这是公平的。在power polluter存在的情况下，如果没有Alita，所有的虚拟机（包括polluter所在的虚拟机）都会被减速。
Section IV. 在线干扰识别模块
在本节中，我们将讨论识别资源污染源的方法，这些污染源会针对内存总线、LLC/带宽和功率等资源产生严重的争用。
A. 总线锁竞争干扰识别
如图1所示，当c0产生split lock时，它会根据MESI cache一致性协议的设计锁住其L1和L2 cache，以防止hyperthreading core访问数据。如果一个虚拟机被分配了一个与c0共享同一物理核的虚拟核，那么其数据访问性能将显著降低。此外，所有其他core（如socket 0中的cn和socket 1中的cm）都可以访问cache中的数据，但无法访问内存。我们使用split lock频率作为检测内存总线争用的指标。具体来说，我们监控每个core中split lock的频率。PMU event SQ.SPLIT_LOCK可以反映core的split lock指标。
假设N个VM在一个节点上同时运行，公式1计算了单个VM和整机的split lock频率
如果SLwhole大于预先定义的阈值ThresSL，则认为该节点受到总线锁干扰。如果Vi产生较高的SLi，那么它就是bus polluter。云供应商根据可接受的数据访问延迟级别配置ThresSL（图6)。我们在Section VII-E评估了Alita对ThresSL的敏感性。对于这样的节点，Alita对bus polluter的split lock进行稀疏化，以确保SLwhole始终小于ThresSL（Section VI-A)。
B. LLC竞争干扰识别
当两个以上的VM共享一个LLC时，量化该LLC的争用级别是非常重要的。图10给出了一个例子。假设三个VM共享LLC空间，如果采用完全隔离，它们的公平配额（基于每个VM的core数）分别为30%、20%和50%。在没有LLC隔离的情况下，Case1中VM分别占用LLC空间的10%、50%、40%，以及Case2中分别占用LLC空间的30%、40%和30%。第一个/第二个虚拟机使用的LLC空间比Case1中的公平配额少/多，但第二个/第三个虚拟机使用的LLC空间比Case2中的公平配额多/少。目前尚不清楚，Case1还是Case2的争议更大。为了量化竞争的程度，我们计算实际分配水平和公平分配水平之间的距离。如果这个距离很小，那么每个应用程序都在使用接近其公平配额的LLC空间，并且争用很低。通过将LLC分配视为一个分布，我们可以使用多种方法来测量两个分布之间的距离。
Alita根据巴氏系数（BC）对LLC竞争距离进行量化，该方法从统计学上衡量两个概率分布之间的相似性。这种方法是有效的，因为公平配额和实际使用量之间的差异反映了争用的程度。
假设n个VM在LLC大小为SLLC的socket上同时运行。让p(x)表示n个VM的LLC分配的概率分布，让q(x)表示在自由共享cache时它们实际LLC分配的概率分布。公式2计算了两个概率分布，其中Ui和Qi分别表示LLC的实际使用量和第i个VM的公平配额。Ui在运行时使用Intel缓存监控技术通过PMU进行测量。Qi计算为Ni/Nall*SLLC，其中Ni是第i个虚拟机中的core数，Nall是机器中的core总数。所有n个VM的q(x)之和等于1。如果所有core都没有被分配，那么所有VM上的p(x)之和不等于1。
公式3计算LLC公平配额和实际使用的概率分布的BC距离。计算出的结果是0到1之间的实数。如果p(x)和q(x)接近，那么BC(p,q)就接近1，并且共址的VM之间不会严重争夺LLC空间。相反，如果p(x)和q(x)差异很大，BC(p,q)就接近于0，说明此时争用是显著的。
根据这种方法，图10中Case1和Case2的BC分别为0.937和0.97。因此，在Case1中，LLC的争用更为严重。如果BC(p,q)小于某个阈值，则LLC的争用被认为是显著的。如果争用不显著，然后允许VM继续共享LLC可以提供高系统性能。如Section VI-B中讨论的，当竞争非常激烈时，Alita将占用远远超过其公平配额的LLC空间的LLC polluter隔离开来，并允许其余的虚拟机共享LLC空间，以获得高系统性能。我们根据经验将BC阈值默认设置为0.8。我们在Section VII-E节讨论了Alita对BC阈值的敏感度。
另一种方法是先确定cache争用是否会影响节点上虚拟机的性能，然后再检查配额的使用情况。此方法适用于已知工作负载的私有云平台。然而，供应商既不知道租户VM的工作负载，也不知道VM在公共云平台上的单独运行性能。由于VM的性能是不稳定的，因此需要广泛分析来确定每个VM的单独性能来支持上述方法，然而显然这种方法不切实际。
C. 功耗竞争干扰识别
为了量化使用多CPU的VM功耗情况，Alita根据每个core的温度和利用率来识别power polluter。我们选择这个方法是因为core的功耗与它的温度密切相关，并且现有架构提供了接口来收集每个core的温度。
图11给出了当linpack和正常的benchmark bs分别在socket 1中使用core 0-5和core 18-23时的温度。
由于linpack导致更高的功耗，它的测试温度更高。socket 0中的core的温度较低，因为它们都处于闲置状态。值得注意的是，即使socket 1中的core 6到18空闲，它们也比socket 0中的空闲core更热。这是因为它们从同一socket中其他运转的core吸收热量。因此，仅仅依靠温度来识别消耗过多功率的core是不精确的。
我们依靠有关利用率的附加操作系统级信息来帮助识别。如果一个core的利用率很高，那么这个core就会忙于执行指令，并且往往会消耗大量的能量。
我们假设m个VM在具有N个core的CPU上同时运行，并且第Nk个内核被分配给第k个VM。Tempjk和Utiljk分别表示分配给第k个VM的第j个core的温度和利用率。公式4和5分别计算分配给第k个VM的core的平均温度（Tempk）和整个socket的平均温度（Tempsocket）。
如果CPU的总功耗接近TDP且第k个VM的core具有高温和高利用率值，那么我们就认为第k个VM是一个power polluter。具体地说，当它满足下面两个约束条件时，它被认为是一个power polluter:
1) VM的平均温度高于socket的平均温度，即
2) VM的core的平均利用率高于CPU的平均利用率，即
D. 调整经验阈值
在生产环境中，为每一代处理器确定一次经验阈值Thressl和ThresBC。在将新一代节点添加到云平台之前，我们将bus polluter和 cache polluter与具有代表性的workload（Parsec和Tailbench）共址到这些节点，以分别确定Thressl和ThresBC的阈值。我们调整了bus polluter的split lock频率和cache polluter的LLC密度，并分析了阈值设置为不同值时的workload性能。然后根据SLA和workload性能设置最终的阈值。这一过程是自动完成的，可以三天之内在一台新机器上，利用2000次迭代（20个workload、10个阈值和10个split lock频率级别/10个LLC密度级别）内完成。如有使用额外的机器，迭代时间会线性减少。这个运行时间完全可以接受，因为新节被添加到云平台中后通常会运行多年。
Section V. 自适应干扰消除
Alita利用总线锁稀疏化、LLC隔离和选择性功率调节来消除因不同资源的竞争而造成的性能干扰。
A. 总线锁稀疏化
由于没有隔离总线锁的接口，我们通过降低bus polluter生成split lock频率来减轻总线锁的干扰。
1) 选择适当的稀疏化技术
根据Section II的分析，稀疏化技术必须遵守两个约束条件。首先，它应该能够显著降低split lock的频率。其次，为了处理突发干扰，其必须具有较短的响应时间。
可以使用多种方法来降低特定core的频率，例如DVFS（动态电压频率调整）、duty cycle占空比和CPU带宽控制。DVFS调整每个core的频率。占空比调整信号或系统活跃的周期占比，其中周期是信号完成一个开/关循环所需的时间。使用CPU带宽控制，目标core高速运行，控制在操作系统级别完成。Linux中的CFS调度器将CPU时间的一部分分配给一个进程。相反，在占空比调节中，占空比配置是在时钟脉冲电平的硬件级别完成的。通过控制一个CPU周期的“开启时间（高电平）”和“总时间（时钟周期）”的比率，可以降低core频率。
图12介绍了DVFS和占空比调节在core中降低split lock频率的有效性。实验中，我们在后端循环执行算法1。图中x轴代表Linux中Turbostat工具采集的core的Bzy_MHz值。Bzy_MHz是core在繁忙（不是空闲）时运行的频率。表1是占空比级别与Bzy_MHz值的映射。在该表中，当core被DVFS配置为第二行由占空比调节对应的频率时，实际运行效果参考第三行“Bzy_MHz(DVFS)”。可以看出，DVFS只能按照100MHz的粒度调整core频率。此外，DVFS无法降频到1000 MHz以下。总的来说，占空比更适合调节split lock频率。
图13给出了当core采用DVFS配置为1600 Bzy_MHz和占空比配置为9级时的split lock频率。可以看出，DVFS的split lock降频效果不够稳定。相比之下，占空比调节能够精准降频。目前尚不清楚DVFS为什么不能持续降频，一个可能的原因可能是Linux中的cpupower模块不够完善。
2) 稀疏化策略
稀疏化策略的目的是确保整个节点的总split lock频率保持在阈值Thressl以下。我们在Section VI-E评估了Alita对阈值Thressl的敏感度。
我们将在过去一段监控期间生成split lock的core称为dirty core。Alita定期检查每个core是否为dirty core，并使用占空比来降低dirty core的运行频率，以确保split lock频率低于Thressl。支撑这种设计的一个假设是，本轮的dirty core在下一个周期内仍有相当高的概率生成split lock。这个假设是有效的，因为core通常是静态分配给VM的，而且VM上的负载相对稳定。
Alita采用基于反馈的闭环控制机制来管理每个core的占空比等级。算法2用于调整每个core的占空比等级。基于Threscore和Thresburst的大小关系（算法2中的第2行），对于core c的处理方式也不同。如果
每当一个core产生高频的split lock，它的占空比被降到一个很低的水平来最小化其split lock频率。这种方案使Alita能够将bus polluter导致的其他正常VM性能损耗降至最低。另一个方案是调整所有core的占空比级别以最大限度地提高系统性能，同时确保总split lock频率保持在
如果一个bus polluter在一个监控周期内没有生成频繁的 split lock，那么它的占空比级别会增加1，这意味着它们可以避免split lock频率的突然升高（算法2中的第10行）。我们的平台支持16个占空比级别（由硬件决定），如果bus polluter停止生成高频的split lock，其占空比级别需要最多15个周期才能返回到最高级。
B. LLC隔离
我们的设计目标是减轻LLC竞争引发的干扰，同时最大限度地提高系统性能。以前有通过动态重新分配LLC的方法来提高系统性能的相关研究。然而，复杂的LLC配置过程浪费时间，而且处理云平台中的突发LLC争用响应速度太慢。
为了实现我们的设计目标，Alita采用了一种简单有效的隔离策略，仅在发生显著竞争时才隔离LLC polluter。
具体地说，Alita只完全隔离LLC占用空间远大于其公平配额的LLC polluter，同时让正常VM共享所有LLC空间。我们将此方法称为bias-isolation方法。虽然Alita后端使用Intel缓存分配技术来调整LLC分配，但它不需要暂停VM来隔离cache polluter。
如Section IV-B所述，当满足两个约束条件时开始采取bias-isolation措施：1）LLC空间已满；2）使用公式3计算的VM实际LLC占用和LLC公平配额的BC小于阈值ThresBC。LLC密集型VM在争用很小（这两个约束条件都不满足）时，使用多于其公平配额的LLC方式是有益的。
图14展示了Alita用于隔离LLC polluter的方法。具体来说，每个LLC polluter被分配一个隔离区域，并且只能使用该区域中的LLC。每个区域的每一行都有一个或多个cache way。公式6计算区域Wregion中原始cache way的数量，用于隔离LLC polluter。在这个等式中，nrways、nrvcore和nrcore分别表示LLC中的cache way数量、LLC polluter占用的core数以及socket中的core总数。所有正常的VM都使用包括整个LLC的默认区域来最大限度地提高性能。
C. 选择性功率调节
在本小节中，我们将提出一个合理的策略来减轻功耗干扰。
1) 选择适当的功耗限流调节技术
节流技术必须能够有效地调节core的功耗。DVFS和占空比调节技术也适用于调节core运转频率，从而减少功耗。图15展示了这两种技术在CPU中的所有core执行耗电Linpack benchmark时降低CPU功耗的有效性。可以看出，与占空比调节相比，DVFS提供了更好的功率调节效果。这是合理的，因为DVFS降低了core的电压和频率，而占空比调节只是执行较少的指令。
与DVFS和占空比不同，平均运行功率限制技术（RAPL）可以直接设置CPU的功率上限，使其成为一个较佳的选择。然而，RAPL仅限于CPU粒度。当CPU的功率达到TDP时，所有core都会被RAPL降频。因此，与power polluter共用一个CPU的进程的性能降低。尽管英特尔最新的Cascade Lake处理器支持单核RAPL，但云平台上的大多数传统节点都使用较旧的处理器。因此，Alita利用DVFS对使用旧处理器的节点执行功率调节，并在使用最新Cascade Lake处理器的新添加节点上使用单核RAPL技术。
2) 限流策略
Alita使用Section IV-C中描述的方法来识别power polluter。我们假设一个CPU上的N个VM被标识为power polluter。Alita会限制这些polluter的power消耗。
Alita定期监控CPU的功耗，并执行算法3调整每个core的功率。如果CPU的功耗接近TDP（大于
Alita首先对高DVFS/RAPL水平的power polluter的core降频。只有当相对较多的core运行power polluter时，CPU的功耗才达到TDP。虽然有许多高功耗core，但通过将所有core的DVFS/RAPL级别降低一档，总功耗可以显著降低。
根据图15来看，Alita可以降低core的占空比，以减少总线争用，从而同时降低core的功耗.。由于占空比和DVFS技术是互不影响的，如果总线干扰和功率干扰同时存在，Alita会独立地进行调整，以保证共址运行进程的性能。如果DVFS或占空比级别太低，则Alita将在下一个运行周期内将其提高。
Section VI. 实验评估
本节中，我们讨论Alita隔离总线锁、LLC、功耗等竞争的有效性，并且展示Alita在生产环境公有云平台上的效果。
A. 实验环境设置
我们在装有两个Intel Xeon Platinum 8163 CPU的服务器上测试Alita。这个CPU的TDP是165瓦。详细的实验装置如表II所示。我们考虑了Parsec和TailBench作为 benchmark，其中包括科学计算负载和延迟敏感型的Internet服务。TailBench中的Xpian（xp）和shore（sh）工作负载是在真实云平台中广泛使用的web服务和数据库workload。
Benchmark fs、x264、xp和sh是内存密集型的，其他benchmark是计算密集型的。我们在VM上运行3dsmax作为bus polluter，在VM上运行CacheBench作为LLC polluter，在VM上运行Mprime作为power polluter。出于简单考虑，我们只把一个polluter和benchmark放在一起。结果证明了当节点上存在额外的benchmark或polluter时，Alita隔离的有效性。
B. 总线竞争隔离
我们没有找到前人关于bus lock的研究工作。本实验中，我们在一个节点的不同socket上同时运行每个benchmark和3dsmax bus polluter，并测量每个benchmark的标准执行时间。算法2的阈值Thressl默认设置为70000次锁/秒（参考第VII-E节）。Bus polluter和benchmark都使用了四个core。实验结果验证了当bus polluter只租一个小的虚拟机时Alita隔离的有效性。
图16分别是有和没有Alita隔离的Parsec benchmark的执行时间（向单独标准执行时间进行了归一化）。如图所示，benchmark的执行时间是没有Alita的单独执行时间的三倍多以上。总体而言，与没有Alita隔离的情况相比，Alita的隔离将Parsec的性能平均提高了2.55倍。Benchmark fs的性能下降幅度最大，因为它是内存密集型的，其性能由数据访问延迟决定。另外，没有Alita隔离的xp和sh的延迟是采用Alita隔离的3500倍以上。由于查询的延迟主要由数据获取延迟决定，所以延迟敏感型服务可能因为内存总线锁的存在而承受非常长时间的延迟。用户查询的数据获取速度会显著下降，这是由高频split lock引起的。
然而，使用Alita的Parsec benchmark的性能下降小于1.2倍，而使用Alita的xp和sh的延迟增长小于其单独性能的1.6倍。由于Alita对bus polluter生成的split lock进行了稀疏化处理，所以benchmark只会受到较小性能下降的影响。
图16同时给出了bus polluter（绿线）的标准化每条指令cycle数（CPI）。我们不使用执行时间作为polluter的性能指标，因为当benchmark完成时，polluter仍然在运行。如图所示，所有测试中polluter CPI值都小于相应单独CPI值的1.8倍。性能降低很低，因为高频split lock导致polluter的单独运行性能较差。这种程度的性能下降对于偶尔产生高频split lock的polluter来说是可以接受的。对于长期polluter，我们联系租户并协助他们解决问题。在Linux5.7补丁中，不管split lock频率如何，polluter都会被杀死。
图17是fs 启用Alita和关闭Alita的CPI值的时间序列。其他benchmark有类似的曲线。本实验中，bus polluter在30秒时开启，Alita在90秒时开启。图17结果表明，在split lock频率较高时，关闭Alita的fs平均CPI为5.72。在90秒启用Alita后，fs的CPI立即下降到大约2.28。
C. LLC竞争隔离
本实验中，我们将两个benchmark与CacheBench LLC polluter放在同一个socket上。两个benchmark应用程序执行同一benchmark的两个副本。我们同时运行多个VM以分析Alita在复杂的LLC竞争场景中的有效性。Benchmark和polluter各使用四个核心。如果polluter使用额外的core，它会占用更多的LLC空间，benchmark在关闭Alita的情况下表现更差。
图18是Parsec/Tailbench benchmark的执行时间/延迟，这些benchmark分别归一化为使用默认的自由共享策略、静态公平隔离和Alita隔离。图中每个条形图代表正常benchmark的平均性能，而该benchmark不是LLC污染源。
可以看到，在Alita的管控下所有benchmark都获得了最佳性能。具体而言，与自由共享策略和静态隔离策略相比，Alita将Parsec的执行时间分别减少了12.1%（bt）和48.5%（fs）。它还将tailbench的延迟分别减少了19.2%和11.9%。由于Alita强制的LLC隔离，polluter的性能略有下降。
对于benchmark应用而言，在自由共享策略下运行性能最差，因为LLC polluter占用了过多的LLC空间。尽管静态隔离成功消除了LLC空间的争用，但它导致了较低的空间利用率。例如，如果cache不是静态隔离的，fs可以使用额外的cache空间。Alita限制了LLC对污染源的使用，但允许普通VM使用整个cache。这种设计保证了正常应用的良好性能。
D. 功耗隔离
在每个实验中，我们将一个benchmark应用与Mprime power污染器放在同一个CPU上。每个benchmark使用4个虚拟核，而power polluter使用24个虚拟核。多个较小的VM组合使用高功率也可能导致普通VM的性能较差。
图19显示了开启Alita时每个benchmark的性能，标准化为其单独的性能，以及polluter的标准化每秒指令数（IPS）（绿线）。Alita将benchmark的性能提高了18.1%。与其他benchmark相比，sc和sh的性能更高，因为这两个是计算密集型的，这意味着它们的性能对core的工作频率很敏感。Alita之所以有效，是因为它只降低了power polluter使用的core的工作频率，而其他core的工作频率却得到了保留。值得注意的是在实验中，power polluter的标准化IPS始终是1。这主要是因为power polluter在core频率较高时没有充分利用core。
图20显示了当Alita开启（40秒）和关闭（160秒）时调整core频率的时间序列。我们可以看到，当Alita打开时，它精确地识别出消耗过多功率的core，并且只降低分配给power polluter的core的DVFS级别（灰色线）。这样，总功耗（红线）保持在预期的高水平，但系统在Alita开启时是保证安全的。此外，bs的core频率根据硬件和操作系统策略而增加。
E. 对阈值的敏感度
Alita使用两个阈值：Thressl用于bus lock稀疏化，ThresBC用于LLC bias-isolation。
图21展示了当Thressl设置为不同值时benchmark的性能。可以看出，当Thressl较低时，性能会更高。这是因为Thressl的值越小，数据访问延迟越短。然而，使用一个非常小的阈值（例如40000）是没有好处的，因为benchmark能够容忍低频的split lock（当阈值Thressl小于70000时，benchmark的性能不会显著降低）。然而，一个非常小的阈值可能会显著降低bus polluter的性能，即使它们只生成低频split lock。我们建议设置Thressl=70000次/s。
为了分析Alita对ThresBC的敏感性，我们将每个benchmark与一个cache polluter共址，调整Alita的ThresBC，并观察benchmark和cache polluter的性能。
图22展示了Parsec的bt和Tailbench xp的性能。其他benchmark也显示了类似的结果。较小的ThresBC值不会对cache polluter启用隔离策略，而较大的ThresBC值会导致整个系统性能较差。因此，我们在公有云平台上将ThresBC设置为0.8。此阈值不会显著降低使用略多于其公平LLC配额的LLC空间的应用程序的性能。
F. 在生产公有云平台上的应用
Alita部署在一个生产公有云平台上，该平台包含30000多个节点和250000个虚拟机（每个节点有24到48个核，每个节点平均放置8到9个虚拟机）使用了两年多。VM由真正的租户操作，并使用不同数量的core。物理节点使用不同代的cpu。虽然Alita已经被证实能够改善正常VM的性能，但我们现在将分析Alita在抑制目标云平台中已确定的资源polluter的资源占用方面的有效性。Section II-A分析了竞争统计信息。
在我们的公有云平台上，Alita一直是开启的。对于每个节点，Alita连续收集每个VM的split lock（每100ms）、LLC使用率（每1s）和每个core的温度（每1s）。我们对LLC和温度测量使用更长的收集周期，以减少监控开销，因为这些值通常不会在极短时间内发生显著变化。先前关于性能隔离的工作也把资源分配周期按秒或更长粒度作出了调整。
图23显示了目标云平台中bus polluter的split lock频率的变化。虽然被识别的bus polluter只租了一个双核虚拟机，但它的split lock频率高达130000次/秒。频繁的总线锁会显著降低同一节点上其他虚拟机的性能（图6）。当split lock频率激增时（图23中为20秒），Alita捕获到到异常并立即生效。一旦启用了Alita，split lock将被稀疏化。
图24显示了目标云平台中LLC polluter的缓存使用情况的变化。当polluter使用两个core时，其公平配额小于5MB。然而在图24中，它在250秒之前占用高达15MB的缓存。只有当预设配额和实际缓存占用的BC值小于阈值ThresBC时，Alita才启用LLC隔离，开始识别干扰并隔离LLC polluter。因此，polluter只能使用5MB的LLC空间（图24中的“Isolation”）。后来，隔离限制逐渐释放，避免被识别的polluter性能显著下降，因为它可能是一个正常的VM，偶尔会使用过多的LLC空间（图24中的“Relax”）。
由于实际应用占用LLC的不稳定性和Alita的灵敏度较高，图24中有些隔离生效的间隔很小。一旦一个LLC polluter被隔离，BC就有可能超过ThresBC，隔离限制将逐渐释放。如果polluter仍然消耗过多的LLC空间，则会再次启用隔离。使用CAT调整LLC分配的额外开销可以忽略不计。为ThresBC设置一个小区间可以消除一些狭窄的间隔。
图25显示了云平台中power polluter占用core的频率变化。当socket上的功率增加时，Alita检测到功耗升高，开始逐级降低power polluter所在core的运行频率。当功耗下降时，power polluter所在core的运行频率又会增加。CPU的总功耗被限制在合理区域内。此外，分配给普通VM的core运行频率仍然很高。
尽管如图3所示经常出现高频的split lock，但上线Alita后，split lock相关的性能抖动没有再出现了。Alita 成功地缓解了在生产的大型公共云平台上的性能干扰和资源竞争。
G. 未来工作
一个让人期待的事情是，未来硬件可能提供接口来分配总线周期。除了内存总线锁、LLC和power之外，节点上的VM还争夺其他资源。例如，一个物理核分出来的不同虚拟核上运行的进程争用一级缓存空间、二级缓存空间和内存端口。VM还在主机操作系统中争夺页表和TLB空间。在公有云平台中，如果处理器和操作系统提供接口来获取每个虚拟机的页表使用情况和TLB使用情况，以及分配一级/二级缓存、页表和TLB的方法，那么Alita就可以实现更全面的隔离。
Section VII. 总结
本文我们提出了Alita，一个由在线干扰识别器和自适应干扰消除器组成的运行时系统。在线干扰识别器监视硬件和系统级事件统计信息，以识别polluter。干扰消除器采用bus lock稀疏化、LLC隔离和选择性功率调节来减轻资源竞争。我们的实验结果和生产云平台的数据验证了Alita的有效性。同时，我们也在继续探索在新平台上解决资源隔离和竞争的手段和方法。
欢迎钉钉扫码进群交流：
往期精彩回顾：