编者按
本文是哈佛大学和谷歌等机构联合研究的一份论文，基于谷歌数据中心工作任务负载整体和细节技术原理的细致分析，并给出了数据中心性能优化的方向建议。对数据中心软硬件架构和性能优化有非常好的指导意义。
参考文献：
Profiling a warehouse-scale computer, Svilen Kanev, Juan Pablo Darago, etc., ISCA’15
正标题：剖析仓库级计算机
作者：斯维伦·卡涅夫、胡安·巴勃罗·达拉戈、金·黑兹伍德等
6 指令缓存瓶颈
图6中显示的自上而下循环细分表明WSC应用程序花费了大量时间在前端停滞。事实上，前端浪费执行槽位在15-30%的范围内（通常比典型的SPEC基准测试中的高2-3倍）。请注意：在前端，这表示指令供应不足；在后端，表示它能够接受更多。由于大量不温不火的代码，我们将这些主要归咎于指令缓存问题。最后，从历史数据推断I-Cache工作集趋势，我们看到，一些应用程序的增长率惊人。
为了更详细地了解前端停顿的原因，我们首先测量前端饥饿周期——当µop队列向后端提供0 µops时的周期。图7显示它们通常超过所有周期的5%。这在存在深度（40多条指令）前端缓冲区的情况下尤其重要，这些缓冲区屏蔽了较小的提取气泡。最可能的原因是不可忽略的一部分长延迟指令未命中事件——最有可能是L2缓存中的指令未命中。
图 7：前端瓶颈上完全饥饿的周期，占执行的5%以上。
图8中显示的高L2指令未命中率证实了这种假设。WSC应用程序通常在5-20 MPKI的范围内未命中，比SPEC CPU2006中的最坏情况更频繁，增加了一个数量级，并且在该区间的高端，比CloudSuite [14]的横向扩展工作负载测得的比率高50%。
如此高的未命中率的主要原因仅仅是WSC应用程序的大量代码占用空间。数百MB的二进制文件很常见，并且如第3节所示，没有明显的热点。因此，指令缓存必须处理大型代码工作集——许多“常温的指令”。这在L2缓存中变得更糟，其中指令必须与数据流竞争缓存容量，数据流通常也有一个大的工作集。
架构师有几个可能的方向来解决指令缓存瓶颈。更大的指令缓存是显而易见的，尽管更高的容量必须与增加的延迟和芯片资源约束相平衡。更复杂的指令预取器是另一种，用于私有I-Cache，在一些重要指令未命中率的情况下非常成功 [3, 26]。最后，缓存分区是另一种选择，特别是考虑到L2和“常温”代码中的高未命中率。虽然在共享的最后一级缓存（Qureshi和Patt[43]等）中对多个应用程序的访问流进行了广泛的分区研究，但很少有人注意区别对待指令和数据流，特别是在专有的中间缓存。最近，Jaleel等人提出修改替换策略，将代码优先于数据[21]，SPARC M7设计团队选择了完全独立的L2指令和数据缓存[30]的架构。
制作大型指令工作集时遇到的问题是一个普遍且日益严重的问题。为了证明这一点，我们使用分析数据来评估数据中心二进制文件在30个月内的I-Cache占用的空间。对于某些应用程序，此类评估空间占用同比增长超过25%，显著超过I-Cache大小的增长。
评估工作负载的工作集大小的规范方法是基于模拟的。它涉及简单地扫描模拟器中的缓存大小，并寻找“曲线拐点”——未命中率下降到接近零的大小。这很麻烦，特别是如果在同一个二进制文件的大量版本上执行以捕捉增长趋势。相反，我们开发了一种不同的、非侵入性的方法来评估它。只有分析数据可用，人们可以使用无序的指令指针样本，并测量有多少唯一的Cache Line覆盖了所有样本的绝大部分（例如99%），当按热度排序时。这种度量背后的基本原理是无限大小的缓存显然会包含所有唯一的Line。在有限大小的缓冲上，在足够大的时间窗口内，LRU替换策略最终会剔除不太常用的Line，直到留下最热的Line。
然而，这样的策略取决于随着时间的推移一致的采样。在一项长期的研究中，被分析的机器的比例和服务于同一应用程序的机器数量可能会有很大差异，通常是难以控制的。在这种差异下，比较两个时间段内覆盖固定样本部分的Cache Line的绝对数量是不公平的——10个以上的样本中有99%更有可能捕获指令Cache Line尾部的绝大部分。
我们用另一层采样进行补偿。对于特定的二进制版本，我们选择固定数量的随机样本进行后处理一周的数据（在下面显示的结果中，这个数字是100万），并计算覆盖该新样本的唯一Cache Line的绝对数量。这相当于在测量期间使用稳定数量的样本构建热度排名。
图8：指令L2缓存未命中率通常很高
图9：大指令缓存占用空间。对于某些应用程序逐渐变大
图9显示了将这种方法应用于30个月的指令指针样本的结果。它绘制了我们对指令缓存工作集大小的估计——特定二进制文件的100万随机每周样本中唯一Cache Line的数量。对于校准，我们包括400.perlbench，它具有SPEC CPU 2006中最大的测量I-Cache工作集 (172 KB) [20]。
首先，所有工作负载都展示了相比SPEC几倍大小的I-Cache工作集。图9说明了search2和bigtable的情况——它们的I-Cache占用是400.perlbench的4倍，相当于688KB或更多。请注意，这样的大小明显大于当前架构中的L2缓存（Intel：256 KB，AMD：512KB，IBM：512KB），这也必须与数据流共享。
更重要的是，这个评估值随着时间的推移而增长，某些应用程序的增长速度惊人。考虑图9中的search2，其足迹在研究期间几乎翻了一番，每年27%。其他工作负载更稳定——例如，bigtable仅同比增长3%。
虽然这种差异的确切原因尚不清楚，但我们假设它与开发速度有关。像搜索这样的产品正在不断发展，并且经常会看到添加了各种新功能，这导致代码更多。另一方面，bigtable是一个相对成熟的代码库，具有定义明确的功能集，开发较少。一项更量化的研究，将开发速度与指令足迹相关联，将使未来的工作变得有趣。
7 CPU Core后端行为：依赖访问
虽然大型指令工作集的负面影响可能会继续增长，但目前由自上而下分解（图6）确定的主要开销来源显然是在内核的后端。
总体而言，大量前端和后端停顿的综合影响导致平均每周期指令数（IPC）很少（图10）——几乎比SPECint的几何平均值低2倍，接近大多数内存的指令SPEC中的约束基准（429.mcf、471.omnetpp、433.milc）。这一结果与已发布的关于经典数据中心工作负载的数据一致[22]，并促使研究人员调查小Core在仓库级应用中的潜力[1, 22, 31]。我们展示了一个更细微的图片，双模提取的ILP，通常很低，但也有更密集的计算周期。
提醒一下，后端绑定微操作槽有两个非常广泛的原因：服务数据缓存请求所花费的时间，以及缺乏指令级并行性 (ILP)。在这两者中，数据缓存行为是我们测量中的主导因素。鉴于WSC工作负载的数据密集型性质，这有点不足为奇。图11用作确认，显示后端周期的数量，由于缓存层次结构中的挂起加载或存储缓冲区容量不足而停顿。在所有周期的50-60%中，它们占前面显示的后端绑定流水线槽的80%以上（图6）。
图10：IPC普遍较低
图 11：一半的周期花费在缓存停顿上
然而，并不是所有的周期都花在等待数据缓存上。我们在图12中证明了这一点，它测量了提取的ILP的分布。通过提取的ILP，我们指的是，当一些μops从乱序调度器发出到执行单元时，每个周期同时执行的μops的数量。我们看到72%的执行周期表现出低ILP（在6发射Ivy Bridge内核上ILP为1或2），这与大部分周期都花在等待缓存上的事实一致。然而，对于其他28%的周期，每个周期有3个或更多的功能单元处于忙碌状态。
与这种行为一致的一种解释是WSC应用程序表现出从属缓存访问和突发计算的细粒度混合。计算突发既可以依赖于缓存引用，也可以独立的作为ILP提取。这两种变体之间的差异——密集的计算阶段是否在执行的关键路径上——可能对“wimpier”内核的最终性能有影响，并且需要专门的模拟研究。
图12：提取的ILP。28%的周期使用6路发射的机器上的3个或更多执行端口。
图13：内存带宽利用率普遍较低。
内存带宽利用率 请注意，在上一段中，我们立即诊断了相关的缓存访问。我们假设这是因为我们观察到的内存带宽利用率非常低，如图13所示。该图是在足够多的机器上测得的DRAM带宽的累积直方图。利用率的第95个百分位数为31%，测得的最大值为68%，最后一个百分位数处有一条粗尾。低带宽使用率的某些部分肯定是由于CPU使用率低。然而，这并不是一个充分的解释——Barroso等人展示中等的CPU利用率，在40%–70%范围内（取决于集群类型）[4]，而我们测得的中位带宽利用率为10%。请注意，低带宽要求与CloudSuite[14]和其他新兴数据中心工作负载[33]的测量没有太大不同。
带宽利用率低的一个后果是，对于当今数据中心中运行的一组应用程序而言，内存延迟比带宽更重要。根据WSC服务器设计，这可能会在内存带宽（或内存控制器的数量）与释放的硅区域的其他用途（例如，更多内核或加速器）之间进行权衡。
请注意，大量未使用的带宽也与一些关注容量的典型基准测试做法相反。例如，通常运行的SPECrate（N个内核上的N个副本）可以将多个基准测试的内存瓶颈从延迟转移到带宽[48]，从而导致架构师针对不太相关的目标进行优化。
8 并发多线程
图14：SMT对架构行为的影响。从上到下：(i) 与图 12 相比提取了更多的ILP；(ii)前端边界周期减少，但 (iii) 指令饥饿仍然存在；(iv) 两个超线程使核心吞吐量翻倍。
到目前为止显示的微体系结构结果没有考虑同步多线程 (SMT)，即使它在分析的Ivy Bridge机器上启用。例如，图6中的顶层循环分解是在每个超线程的基础上完成的，假设每个超线程都有完整的机器宽度来发出µops。
从广义上讲，当工作负载具有不同的性能瓶颈时，SMT的效率最高，多个线程可以相互补充不足。WSC应用程序在前端和后端都效率低下，并且怀疑存在细粒度的相位行为，非常适合这样的描述，我们希望它们能从SMT中受益。
虽然我们无法在不干扰大量面向用户的服务（即禁用SMT并查看工作负载性能）的情况下对反事实进行大规模测量，但我们至少可以通过比较特定的数据来估计SMT的效果。每个超线程性能计数器，其中的计数器基于每个核心聚合。请注意，这与测量单个应用程序从SMT体验到的加速非常不同。当一个线程在一个内核上共同运行时，与拥有完整内核时相比，它的性能自然会下降——主要是由于容量效应，即必须共享微架构单元和缓存。另一方面，核心利用率增加仅仅是因为多个线程共享它。虽然我们无法在不关闭SMT的情况下大规模测量第一个效果，但我们可以并且确实测量了后者。
正如预期的那样，当考虑到SMT时，后端的功能单元利用率会增加。图14中的第一幅图显示，在对两个超线程进行计数时，在34%的周期内使用了6个执行端口中的3个或更多，而在图12中，单独计算每个超线程时，这一比例为28%。
虽然SMT的这种改进在意料之中并且得到了很好的理解，但对前端性能的影响却不太清楚。一方面，SMT会增加指令缓存压力——需要获取更多指令，即使超线程共享相同的代码，加剧了本已严重的指令缓存容量瓶颈（第6节）。另一方面，一个超线程上的长延迟提取气泡可以通过从另一个超线程中提取来吸收。
我们的分析数据表明，后一种效应在WSC应用程序中占主导地位，而SMT最终提高了前端利用率。从图14的第二个和第三个图中可以明显看出这一点。每核前端边界周期明显低于每超线程测量时 - 中位数为16%与22%，它们周围的分布更加紧密. 前端饥饿周期（没有调度微操作）也从5%减少到4%，表明长延迟指令缓存未命中得到更好的吸收，并且SMT成功地缓解了一些前端低效率。
但是请注意，即使在我们考虑2路SMT之后，75%的已收集集群样本显示的IPC值仍为1.2或更低（图14的最后一个图），而理论机器宽度为4.0。再加上延迟瓶颈（由于从L3缓存获取指令和从主内存获取数据）仍然远未消除，这表明更广泛的SMT的潜力：每个内核有更多线程，如某些服务器芯片中所见[ 30]。前面显示的低内存带宽利用率加强了这种情况——即使每个核心带宽有更多线程也不太可能成为瓶颈。这些结果值得进一步研究平衡更广泛的SMT的好处与潜在成本，无论是在性能方面，还是潜在地遇到容量瓶颈，
9 相关工作
近年来，对为数据中心开发新架构支持的研究兴趣显着增加。部署“wimpy cores”或微服务器来优化数据中心的概念已经得到很好的探索 [1, 22, 31]，最近的努力已经研究了专门的互连 [32] 和定制的硬件加速器 [42]。虽然我们的周期分解找到了专业化的机会，但微架构分析表明，“强壮的”无序超标量内核提供了足够的性能，尤其是在与宽 SMT 结合时。正如先前的研究所观察到的那样，“弱”内核和某些形式的专业化在成本和功率效率方面表现出色，但通常以牺牲性能为代价。
数据中心处理器设计中的架构研究激发了多项学术努力，以开发用于数据中心计算的基准套件。最值得注意的是，CloudSuite 是横向扩展云服务工作负载的混合体，以现代服务器系统为特征 [14]。最近的努力提供了CloudSuite[49] 部分的深入微架构特征。我们的一些发现（非常低的带宽利用率）在CloudSuite基准测试中得到了很好的体现，其他的——在较小程度上（大的I-Cache压力），而另一些则明显不同（非常平坦的执行配置文件与热点）。许多后续架构研究不公正地只关注CloudSuite的Web搜索部分。这可能会导致错误的结论，因为：(i) 网络搜索不是数据中心中唯一的“杀手级工作负载”；(ii) CloudSuite Web Search 与我们在实时 WSC 中的发现相关性最低（它看到非常短的停顿时间，具有很小的 L2 指令工作集，因此，实现了非常高的 IPC，更能代表计算密集型工作负载 [14]）。同样，DCBench 更深入地关注云数据分析 [23]。这些套件对于实验至关重要，尽管它们不能像观察多年来大规模发展的生产应用程序那样全面。
其他研究人员也采用了分析实时数据中心的方法。科兹拉基斯等人。提供了来自Microsoft（Hotmail、Cosmos 和 Bing）的互联网规模工作负载数据，但他们的研究更侧重于系统级Amdahl比率，而不是微体系结构的影响 [27]。另一篇论文[5]同样关注谷歌网络搜索的系统问题。虽然它对微体系结构有一些讨论，但这项研究现在已经有十多年的历史了。大量工作配置文件生产仓库规模的应用程序，其明确目的是测量 [24] 和减少 [35, 50] 共同调度作业之间的冲突，或根据机器特性 [34] 调度它们。此类研究可以受益于此处提供的微架构见解。
最后，我们的工作建立在对现代硬件上的应用程序进行概要分析和分析的现有工作之上。Google-Wide-Profiling 在 Google 的数据中心机群中提供了低开销的性能采样，并且已经部署多年以提供纵向研究的能力 [44]。我们还利用自上而下性能分析 [48] 的最新进展，使我们能够在没有专门硬件支持的情况下估算 CPI 堆栈 [13]。
10 结论
为了更好地了解数据中心软件的性能特性，我们对一台仓库规模的计算机进行了几年的分析。在本文中，我们展示了跨越数万台机器、运行数千个不同应用程序、同时执行数十亿用户请求的详细微架构测量。
这些工作负载在应用程序本身和每个应用程序内部都表现出显着的多样性。通过跨二进制文件分析，我们发现了常见的低层级功能（“数据中心税”），这显示了未来服务器SoC中专用硬件的潜力。最后，在微体系结构层面，我们确定了WSC应用程序的一个共同特征——低IPC、大指令占用空间、双模ILP和对带宽的延迟偏好——这将影响数据中心未来的处理器设计。这些观察激发了未来仓库规模计算机的几个有趣方向。下表简要总结了我们的发现和对架构设计的潜在影响。
上表是调查结果的总结及对未来调查的建议。
作者：Svilen Kanev etc
来源：https://mp.weixin.qq.com/s/W3FOWorzGqehV9Aep7os\_A
微信公众号：
相关文章推荐
更多软硬件技术干货请关注软硬件融合专栏。
