ARM big.LITTLE 系统的软件技术
Robin Randhawa，首席工程师，2013 年 4 月
简介
移动应用已经发生了显著变化，当今的消费者更多地将智能手机应用于大部分互联生活。其中既包括高性能任务，例如网络浏览、导航和游戏，也包括那些要求不太苛刻的“始终在线，始终连接”后台任务，例如语音呼叫、社交网络和电子邮件服务。因此，移动电话已经成为很多消费者必不可少的计算设备。同时，平板电脑等新型移动设备也在重新定义计算平台，以应对消费者的需求。这一趋势为消费者创造了全新的内容互动方式，将以往只可能在固定设备上实现的应用带到移动设备上。这才是真正的智能下一代计算。
摩尔定律将如何往下发展？人们过去预测集成电路上可容纳的晶体管数目每隔 18 个月会增加一倍，直至从数千个增加至数十亿个晶体管，但如果真正审视单个处理器，却会发现它的性能增长停滞不前，因为您可以在系统中消耗的电能已经达到峰值。
对于未来的任何一款处理器，散热必然会限制其速度的大幅提高。一旦达到器件的热障，器件会融化，如果是在移动电话上，设备会开始发热，让用户感到不适。除了物理散热问题之外，能效也会变得相当低。如果调节处理器实施，使其速度逐渐加快，则其能耗将呈指数级增长，而为了增加最后这一丁点的性能，却会导致成本大幅提升。过去，尺寸增大一倍也意味着速度提高一倍，但到了现在，尺寸增大一倍却只能将速度提高几个百分点，因此出于复杂性的原因，效益不复存在，这也是单核系统的速度达到极限的原因之一。
如果您无法让单核运行更快，则必须增加核心的数量。这样做的好处还包括让每个核心能够匹配其承担的工作负载，这正是 ARM big.LITTLE™ 处理概念的用武之地。
Big.LITTLE处理技术可以解决我们当前面临的一个最大难题：扩展消费者的“始终在线，始终连接”移动体验，同时改进性能，延长电池续航时间。实现这一目标的方式是将“big”多核处理器与“LITTLE”多核处理器配合使用，根据性能要求，为适当的任务无缝选择适当的处理器。重要的是，这种动态选择对在处理器上运行的应用程序软件或中间件是透明的。 设备中采用的最新一代big.LITTLE 设计将高性能Cortex™-A15 多处理器集群与高能效Cortex-A7 多处理器集群组合在一起。这些处理器保持了 100% 架构兼容性，并且具有相同的功能（支持 LPAE 和虚拟化扩展，以及 NEON™ 和 VFP 等功能单元），这使得针对一种处理器类型编译的软件应用程序能够在其他处理器上运行，而无需进行修改。
big.LITTLE 系统的结构
两个多处理器集群在集群内部和两个集群之间都保持完全缓存一致。这种集群间一致性是通过 ARM 的 CoreLink™ 缓存一致性互联
(CCI-400) 实现的，该技术还能实现与各个组件（例如 ARM Mali™-T604 等 GPU 系统）的 I/O 一致性。两个集群中的 CPU 可以通过共享的中断控制器（例如 CoreLink GIC-400）相互发出信号。
big.LITTLE系统中的执行模式
由于同一应用程序可以设计成无需修改即在
Cortex-A7 或
Cortex-A15 上运行，这样就有机会将应用程序任务随机分配给适当的处理器。正是基于这一事实，我们提供了多种执行模型，即：
1. big.LITTLE 迁移模型
2. big.LITTLE MP 模型
顾名思义，迁移模型允许从一个类型的处理器捕捉软件上下文，并将其恢复到另一个类型的处理器上。在 CPU 迁移中，集群中的每个 CPU 都与另一个集群中的对应 CPU 配对，软件上下文在集群中的单个 CPU 之间随机迁移。如果集群内没有活动的 CPU，则整个集群和关联的二级缓存可能关闭。
MP 模型允许软件堆栈分布在两个集群中的处理器上。所有 CPU 可能同时运行，提供最高系统性能。
big.LITTLE 迁移模型
迁移模型是 DVFS（动态电压和频率缩放）等功耗和性能管理技术的自然延伸。迁移操作类似于 DVFS 运行点转换。随着负载的变化，处理器的 DVFS 曲线上的运行点会来回变动。当前处理器（或集群）达到最高运行点时，如果软件堆栈需要更高性能，就会执行处理器（或集群）迁移操作。此后将由另一个处理器（或集群）执行任务，该处理器（或集群）上的运行点会来回变动。当不再需要高性能时，可将执行复原。
显而易见，一致性是实现所要求的快速迁移的关键促成因素，因为它能让已经保存在出站处理器的状态在入站处理器上监听和恢复，而不必通过主内存。此外，由于出站处理器的二级缓存具有一致性，当任务迁移之后，它仍然可以维持供电状态，通过监听数据值，改进入站处理器的缓存预热时间。但是，因为出站处理器的二级缓存也无法进行分配，最后还必须清除并关闭电源以节省耗散功率。顺序如下所示。
big.LITTLE CPU 迁移模型
在 CPU 迁移中，LITTLE 集群中的每个处理器都与 big 集群中的一个处理器配对。CPU 分成 CPU 对（Cortex-A15 和
Cortex-A7 处理器上的 CPU0 和 CPU1，依此类推）。使用 CPU 迁移时，在每个处理器对中，同一时间只能使用一个 CPU。
CPU 迁移模型
系统主动监控每个处理器上的负载。高负载会导致执行上下文转移至 big 核心，同样，当负载较低时，执行又会转移至 LITTLE 核心。在任何时候，每个配对中只能有一个处理器处于活动状态。当负载从出站核心转移到入站核心时，前者便会关闭。这种模型让 big 核心和 LITTLE 核心的组合能随时保持活动状态。
big.LITTLE MP 工作方式
由于big.LITTLE 系统通过CCI-400 实现了完全一致性，因此有另一种模型能让Cortex-A15 和Cortex-A7 处理器同时打开并同步执行代码。这种模型称为 big.LITTLE MP（本质上是一种异构多重处理模型）。这是 big.LITTLE 系统最先进灵活的模式，能够跨越两个集群调整单个执行环境。在这种使用模型中，如果活动线程需要相应水平的处理性能，则将打开 Cortex-A15 处理器核心，并让它与 Cortex-A7 处理器核心同时执行线程。否则只需打开 Cortex-A7 处理器。由于处理器核心没有显式匹配，因此使用 MP 模式可以更加容易地支持非对称集群拓扑。
使用 big.LITTLE MP 模式，操作系统的任务调度程序能够识别不同处理器的功耗和性能，并将任务分配给适当的处理器。在这种模式下，操作系统在所有集群中的所有处理器上运行，而这些处理器可能同时运行。操作系统尝试将任务分配给最适合运行这些任务的处理器，并且关闭未使用的或使用不充分的处理器。
ARM 生成了针对 Linux内核的一系列修改，称为ARM big.LITTLE MP HMP 补丁。这些修改已在 ARM 的 big.LITTLE 测试芯片上运行的Android 系统中进行了评估，提供出色的功耗和性能。
Linux 内核中的多处理器支持功能假定所有处理器都具有相同性能，因而任务可以分配给任何一个可用处理器。因此，要支持整个 big.LITTLE MP 模型，必须对 Linux 的调度和电源管理组件进行重大更改。这项工作在开放社区中进展非常顺利，第一批芯片器件的测试结果非常可观。
在移动设备上的使用情况
big.LITTLE架构之所以具备优势，要归因于典型移动设备工作负载的一个特性：它们的性能要求各不相同。下图显示在当前发售的基于 Cortex-A9 的移动设备中，两个核心处于 DVFS 状态、空闲状态和完全关闭状态下的时间百分比。在图中，红色区域代表最高频率运行点，绿色区域代表最低频率运行点，介于两者之间的颜色则代表中间频率。除了 DVFS 状态之外，操作系统电源管理功能也会使 CPU 空闲。图中的淡蓝色区域表示此类空闲时间。当 CPU 空闲时间足够长时，系统电源控制软件可能完全关闭其中一个核心，以节省耗散功率。图中最深的颜色代表这部分时间。
图 6：低强度用例的 DVFS 状态分布
从图中可以清楚地看出：应用处理器在多种普通工作负载下，都有相当长的时间处于低频率状态下。在 big.LITTLE 系统中，SoC 可以使用能耗较低的
Cortex-A7 CPU 来运行除深红色部分之外的其他所有工作负载。在下图中，我们通过相同的方式，对更高强度的工作负载进行了分析。即便在这些用例中，仍然有很大可能将低于 1GHz 频率的工作负载分配给 Cortex-A7 处理器，该处理器提供的每时钟性能仅相当于 Cortex-A9 的 5~10%。
图 7：低强度用例的 DVFS 状态分布
能和功耗分析：big.LITTLE 测试芯片
自2011 年起，用户级软件一直基于big.LITTLE 调度运行，但只在核心和互连的软件模型上运行。为了充分评估 big.LITTLE 系统的性能、节能以及调节是否合宜，必须构建一个能够全速运行用户软件的测试芯片。ARM 测试芯片早在 2012 年初夏即由制造工厂完成，并在短短几周内开始在开发板上运行，运行完整版的 Linux 和 Android Ice Cream Sandwich。（也运行 Jelly Bean，但本文仅提供 ICS 系统的测试结果）。测试芯片包括双核 Cortex-A15 集群、三核 Cortex-A7 集群以及 CCI-400 缓存一致性互联。测试芯片没有包括 GPU，这会影响一部分用户基准测试，但平台仍然可以运行 Linux 和 Android 操作系统以及基准测试软件。
图3 中的性能基准测试在Cortex-A15 和Cortex-A7 CPU 集群上独立运行。测试芯片上的Cortex-A15 的最大频率为1.2GHz，Cortex-A7 的最大频率为 1 GHz。基准测试显示，虽然测试芯片上的存储器系统性能不如量产 big.LITTLE SoC 的预期水准，但 Cortex-A15 和Cortex-A7 CPU 的性能仍然处于预期性能范围内。基于独立运行的核心的测试结果，我们充分相信该平台可以精确地测量 big.LITTLE 架构的性能。测试芯片平台上的软件包括基本 Linux 内核，它应用了 CPU 迁移软件和big.LITTLE MP 补丁集，以允许测试CPU 迁移模型或 big.LITTLE MP 模型。
用于测试 big.LITTLE 性能的主要工作负载是进行网页循环的网络浏览器基准测试，在 Android ICS 上运行，后台有音频播放。在这一用例中，在运行很高强度的工作负载的同时，还运行一个低性能要求的后台活动。网络浏览器每 2 秒进行网页循环，每个页面上执行 500 像素的页面滚动操作，这对系统提出了相对较高的性能要求。运行此基准测试时，在测量性能和功耗的过程中，首先必须确定性能和功耗基线。该基线是在 Cortex-A15 CPU 集群单独运行时测量的。
应该提到的是，这组结果属于很早的测试结果，用来测试早期版本的 big.LITTLE MP 补丁集，该补丁集将 Linux 调度程序从一个完全平衡的调度模型向 big.LITTLE 模型调整。随着软件的优化，我们预期性能和功耗将得以进一步改进，另外我们还会研究更多可调节元素。另外值得一提的是，由于测试芯片上没有 GPU，因而导致 CPU 负载高于有 GPU 为其分担负载的系统情况，而在 CPU 负载较低的状况下，可能会更多地使用 LITTLE 核心，以达到节能目的。它还具有一组基本的电压和频率运行点，但没有对单一处理器核心进行独立的电源开关设计，因此量产的 big.LITTLE SoC 有望提供更好的测试结果。举例来说，后台任务运行可以节省超过 70% 的能耗。
选择 big.LITTLE 软件模型
我们经常遇到的问题是：“应该选择哪一种软件模型？”目前的选择实际上是在 CPU 迁移模型和 big.LITTLE MP 模型之间两选其一，两者各有利弊。在 CPU 迁移中，big 和LITTLE 核心是配对的，因此对称式拓扑可以顺畅运行。而在非对称式拓扑中，big 核心和 LITTLE 核心的数量不相等，因此需要额外的工作。鉴于 Cortex-A7 CPU 核心尺寸较小，因此使用四个 LITTLE 核心加上一个或两个 big 核心的作法可能具有吸引力。从积极的角度来看，CPU 迁移让功耗和性能的调节变得更加容易，可重复利用现有的操作系统电源管理代码，这意味着我们多年的开发和测试可为实施提供支持。由于无需对内核调度程序进行修改，因此就范围而言，CPU 迁移模型的实施比 big.LITTLE MP 模型更加简单，而软件当前也更加成熟。总而言之，CPU 迁移是一种极佳解决方案，适用于在 2013 上半年推出的产品，在该期限以外，对于那些不希望升级到 big.LITTLE MP 模式的系统，它仍然是一种可用的解决方案。
big.LITTLE MP 具有多项技术优势，虽然当前技术尚不成熟，但目前已经进入开发高级阶段，正如本文所示，其测试结果相当不错。由于 big.LITTLE MP 模型的标准支持非对称式拓扑，而无需进行软件修改，因此它可以充分利用系统中的所有核心。它为提升性能和降低功耗提供了更好的机会。例如，big.LITTLE MP 能够同步利用所有核心，从而达到更高的性能，或者通过不同方式调节 big 核心和 LITTLE 核心上的 DVFS 设置和调度程序设置，以节省更多功耗。它允许调度程序更加精细地选择核心，而且通常提供更多调节参数。在提供更高灵活性的同时，也存在一个弊端，因为它需要更多调节，才能充分发挥 big.LITTLE MP 平台的性能和功耗优势。这与几年之前的移动 SoC 并无太大差异，即由芯片供应商 OEM 事先调节设备的操作系统电源管理设置和 DVFS 参数，但 big.LITTLE MP 进一步扩展了这个调节过程，将新参数也包括在内，从而实现更多节能，并且提高经过性能优化的“big”核心的响应能力。
big.LITTLE MP 模型正在快速成熟，但尚未上升为主流。该模型已经可以实现合作伙伴集成，有望在2013 下半年推送至上游。幸运的是，我们无需进行任何硬件更改，即可支持 big.LITTLE MP 模型，因此芯片供应商可以部署采用 CPU 迁移模型的平台，后期对已部署平台进行内核更新，从而升级到 big.LITTLE MP 模型，或者立即构建 big.LITTLE SoC，在 2013 下半年直接使用big.LITTLE MP 软件。
虽然 big.LITTLE MP 尚未在生产中部署，但如本文所示的测试结果中所演示的，软件已经在运行中，并且已在供应商芯片开发平台上进行了演示。big.LITTLE MP 软件可在我们的测试系统上即时投入运行，而当前的工作主要集中在软件强化，针对各种用例来调节系统性能以达到最佳效果。正在实施的一些可调节元素包括调度程序的负载平衡政策、上下迁移点以及线程优先级。ARM 正与芯片合作伙伴协作，进行以上所有方面的系统调节。ARM 以开源方式每月定期发布 big.LITTLE MP 补丁集，内含测试芯片平台的最新调节、测试结果和文档。当前补丁集可从 Linaro 获取，地址为：http://git.linaro.org/gitweb?p=arm/big.LITTLE/mp.git;a=summary
CPU 迁移软件目前仅提供给 Linaro 成员。
下一代 big.LITTLE 硬件
Cortex-A15 和 Cortex-A7 核心代表第一代big.LITTLE 硬件。ARM 已经发布 2 款能够执行big.LITTLE 处理的新型 CPU 核心，即 Cortex-A57 和
Cortex-A53 处理器。Cortex-A57 处理器是经过性能优化的 CPU，相比Cortex-A15 处理器，每时钟周期的性能高出 25%，频率能力更高，效率也稍高。Cortex-A53 处理器则为 LITTLE 核心，每时钟周期的性能相比Cortex-A7 处理器高出 40%，能源效率大约等同于后者。
这些新处理器在架构上相同，并且支持 ARMv8 架构，该架构引入了经过改进的 NEON 和浮点功能、加密加速功能以及 64 位支持。除了 AMBA4 ACE 之外，两种核心还支持下一代一致性互联，它们可在 AArch32 模式下运行，通过与当前的 ARMv7 CPU 核心相同的方式运行现有代码。64 位支持和更多的通用寄存器通过简单高效的方式实施，而且功耗增加不多。微架构也经过增强，以提高各核心在每个指令时钟周期中的吞吐量。在经过软件次要更新以支持 64 位寻址模式后，这些新款核心将与当前的 Cortex-A15 和Cortex-A7 处理器一样支持big.LITTLE 技术。两款处理器将在 2013 年提供给主要芯片合作伙伴，预期在 2014 年投入芯片量产。同时，三星和瑞萨电子已经发布和演示了基于Cortex-A15 和 Cortex-A7 的首款big.LITTLE 芯片，2013 年至少还有另外五家 ARM 合作伙伴计划big.LITTLE 实施。
结论
本白皮书介绍了 ARM 推出的首个big.LITTLE 系统。完全一致性系统与Cortex-A15 和Cortex-A7 组合在一起，提供当前高性能移动平台上不可能实现的新处理机会。
big.LITTLE系统为实现功耗和性能控制点的极宽动态范围提供了可能性。这也是仅包含单种类型处理器的实施所无法实现的。这种宽动态范围可为当前设备上的工作负载提供完美的执行环境，这些工作负载通常同时包括高性能要求和低性能要求的线程。此外，它还提供了创造极高能效的 Cortex-A7 实施的机会，因为它将是平台的动力引擎。
通过这些实施技术和各种使用模型，big.LITTLE 提供了在下一代移动平台中提升性能和延长电池寿命的机会。