为什么需要利用硬件辅助调节机制

想象一下，你醒来后发现自己是一名系统集成商，正在组装未来的“车载计算机”——你有一个强大的异构片上系统(SoC)可供使用，作为集成平台，这个SoC具有通用核心、gpu、其他加速器和足够多的内存集群——简而言之，一个芯片上封装了巨大的功率。您将得到一组由不同供应商开发的经过良好测试的应用程序，这些应用程序具有不同的服务质量(QoS)要求，例如，一些应用程序具有严格的实时要求，以及不同的安全临界级别。您的工作是将这些应用程序组合部署在车载计算机上，并确保所有应用程序都像在各自的竖井设置中运行时那样运行。简单明了，有人可能会说，这些都是预先测试过的应用程序，有足够的计算能力!因此，您需要谨慎地将它们部署在最合适的计算单元上，并让系统运行起来，期望一切都能无缝且高效地工作。相反，一切都乱套了!对时间要求严格的应用程序在新的集成平台上错过了截止日期，并且比它们在自己的设置中表现得更差。那么引擎盖下面到底出了什么问题呢?您可以做些什么来确保时间关键型应用程序获得满足需求所需的所有资源?

理解硬件和软件之间的交互一直是构建高效和可预测系统的关键-随着现代异构soc提供的巨大复杂性和潜力，对这方面的需求只会变得比以往任何时候都更强烈和更迫切。异构soc似乎是集成平台的理想候选，因为它们本质上是为承载不同的工作负载而设计的。

然而，如果我们进一步观察，在这些平台上协调性能和可预测性并不简单。这是因为这些平台的设计是为了优化平均吞吐量、功率和成本，而不是为了可预测性。因此，如图1所示，大多数平台都具有这样一种设置:多个核心共享最后一级缓存以及不同的计算单元，例如通用处理核心集群、图形处理器和其他显示控制器通过一组公共互连共享相同的主内存。

共享资源的存在在程序的执行和对它所操作的数据的访问之间引入了很强的相关性，同时在同一芯片上并发运行的应用程序之间产生了很强的时间相关性的高度干扰。这些影响可能是剧烈的。例如，在Nvidia Tegra X1 SoC上，在单个核心(隔离)的顺序读取场景中，每个字的平均读取延迟低于10 ns，而当来自其他三个核心的同时内存访问受到干扰时，则增加到50 ns以上。(详情请参阅混合临界状态下CPU核心和集成gpu之间的内存干扰特性平台）.

这表明，应用程序的执行时间可能因其内存访问模式和执行上下文而有很大差异。共享资源的存在也被认为是设计依赖于暂时隔离和不受干扰原则的可预测系统的一个主要障碍。简单地说，底层平台应该具有特性/机制，可以最大限度地减少应用程序执行时间的可变性，并保持应用程序行为的可预测性，并且独立于系统中其他共同运行的应用程序。

然而，事实并非如此:上述大多数共享资源都由面向吞吐量的仲裁器管理，并且不知道在核心上执行的应用程序和请求的重要性和重要性。这将导致时间关键型应用程序的性能下降。例如，使用共享缓存，在一个核心上运行的时间关键型应用程序的缓存行可能会被另一个核心上共同运行的应用程序清除。因此，根据共同运行的应用程序的内存访问模式，候选应用程序的执行时间可能有很大差异。

类似地，在DRAM级别上，计算请求的内存访问延迟也不是简单的。大多数内存控制器采用开页策略，目的是通过利用内存请求中的行局部性来优化平均性能。这是通过推测在内存访问后保持激活行打开来实现的，希望下面对银行的请求针对相同的行，从而消除激活和预充电银行的延迟和功耗开销。内存请求调度器还会重新排序请求，优先选择以银行中的打开行为目标的请求。尽管这是有效的，但它导致了不可预测性。使用这种策略，时间关键型任务可能会遭受性能下降，因为它们的内存请求是在非关键任务的请求之后提供的。此外，在互连级别上，不同内存主机之间存在竞争——通用核心、gpu、dma和共享互连的其他加速器——如果没有对不同内存主机发出的流量进行优先级排序和调节的能力，就不可能确保重要应用程序的QoS。

现代异构soc越来越多地提供调节旋钮，可以帮助设计机制，以促进时间隔离和免受干扰。

例如，大多数现代处理器都提供硬件性能计数器，使系统设计人员能够实时监测微架构事件，如缓存丢失、总线周期、写暂停、分支错误预测等。可以利用这些计数器来调试性能瓶颈和了解应用程序的行为。此外，它们还可以用于开发操作系统或管理程序级别的管理机制。其中一个突出的例子就是MemGuard，这是一种在核心级别监视和调节内存带宽的机制。

芯片供应商还在互连级别提供QoS机制，以调整由不同内存主机(如核心和gpu)发出的内存流量。例如，ARM soc允许在每个主节点的互连级别上调节未完成交易的数量和平均交易率等参数。

这些互连级的调节旋钮可用于确保没有单个主控制器垄断对内存的访问，并动态地重新编程相关寄存器，以获得时间关键型应用程序所需的QoS级别。

未来像Arm DynamIQ这样的平台还将提供硬件辅助的动态缓存分区机制，允许应用程序拥有一个虚拟专用缓存，有助于缓解共享缓存的问题。同样令人感兴趣的是内存分区和监控(MPAM)，这是一种硬件规范，用于分配和监控内存子系统的资源，以满足应用程序的QoS要求。有了这个，我们可以期待一些功能，比如用指示器标记内存事务，在不同的master之间实现流量优先级。

构建可预测的系统是一个硬件-软件协同设计问题。在应用程序和中间件级别强制可预测性的软件机制必须与OS/hypervisor级别的机制相辅相成，后者利用硬件管理机制为不同的应用程序提供所需的QoS。考虑所选择的硬件平台对性能和可预测性的影响，传统上是软件设计过程中的事后考虑——这种心态需要改变。我们必须承认，再多的软件调优也不能缓解底层硬件带来的问题。建立可预测系统的建设性机制必须从开发过程的一开始就采用，不能在以后的阶段加以改进。

在这篇博客文章中，我们简要概述了在设计可预测计算平台时所面临的问题。我们将定期在这里发布新的帖子，在那里我们将分享更多关于我们使用这些硬件调节功能的经验的细节。