作者：黄烨锋
EET电子工程专辑原创
Intel今年Q4准备要推的12代酷睿处理器，会同时采用两种不同的核心——Intel称其为P-core和E-core，分别对应于性能核与效率核。放到Arm这边，与大小核(big.LITTLE或DynamiQ)的思路类似。
不过在一颗处理器上采用不同的核心，对调度来说又可能造成相当大的难题。到底哪些任务放到P-core或大核上执行，哪些放在E-core或小核上执行，何时做迁移，很多时候并不是个简单的事情——而且这非常影响用户的使用体验。这就非常考验操作系统的scheduler本领有多高强了。
前不久的Intel Architecture Day上，一方面是Intel强调了自己的Intel Thread Director机制，可辅助操作系统做调度决策——不过可能特指Windows 11;另一方面则是微软为Intel站了台，提到Windows 11对于Intel Thread Director的支持，以及在scheduler方面与Intel之间的合作。
上周Intel在国内追加了一场媒体答疑专场，也再度谈到了Intel Thread Director。我们趁此机会，从高抽象层级来谈谈这种调度决策方案;顺带也聊一聊Arm在这个问题上的一些过往。虽然可能会谈得比较散，不过期望对于我们在不同核心调度方面的理解能起到一定的帮助。
Arm历史上的两次重要转变
Arm发家于低功耗使用场景，虽然这两年在高性能领域也多有渗透，不过Arm的小核心IP理念始终是“顺序执行”指令。而乱序执行固然能够提升性能，但它需要耗费更多的电路逻辑来实现乱序，晶体管和互联数量都会大幅增加，功耗亦随之上升。
Arm最初在设计big.LITTLE大小核方案的时候，就是基于顺序执行更节能，乱序执行性能更强但功耗也高，这一逻辑。于是顺序小核心用来节能，乱序大核心则用于提升性能。当然了，我们知道苹果的处理器虽然也基于Arm指令集，但在大小核设计上就不是这么干的，这是另一个话题了。
虽然我们没有仔细去考察Arm历史上的调度机制变迁，不过至少有两次方向的重要转变是值得一提的;而且Linux、谷歌、芯片厂商、OEM厂商在这其中也做出了相当多的探索和改进。
早年Arm给过一张big.LITTLE设计不同处理器核心的实施方案，其一是以大核丛集和小核丛集为单位的整组迁移——这种方案是最暴力的，操作系统scheduler一次只能看到一个丛集。同一时间只能有一个丛集是活跃状态，负载要么就是在大核丛集，要么就是在小核丛集。早年的三星Exynos和英伟达Tegra就是这么做的。
后来发展出了in-kernel switcher，也就是上图中间的CPU Migration，一个大核和一个小核成对。操作系统scheduler可以看到4个处理器对，同一时间每一对就只有一个核心可以处在活跃状态——也就是整颗处理器同一时间只有一半的核心是工作的。
不过这些上古传说并不是重点。近代比较具有代表性的是GTS(global task scheduling)，或者也叫HMP(heterogeneous multi-processing)——操作系统scheduler能够看到所有的处理器核心，任意时间它们都能激活。当然这只是个大方向的切分，其中还有很多转变细节。
我们所知采用完整GTS调度方案的应该是海思Kirin 920时期的荣耀6手机(2014年)。在Linux Kernel 3.8之后，融入了一种针对每个scheduler entity(一个进程或进程的一个Cgroup)做持续负载追踪的机制——名为per-entity load tracking(PELT)，这是GTS的核心所在。在此之前(Linux Kernel 3.7和更早版本)CFS(completely fair scheduler)是基于per-run-queue队列追踪的。具体的这里不展开，不过per-entity load tracking应该算是比较大的一次转变。
GTS事实上是Arm和Linaro共同开发的。这类机制也算是芯片生态中非常重要的组成部分了。PELT有三个最主要的控制参数，上阈值、下阈值(由内核scheduler定义的值)和平均负载周期(决策制定的时间窗口)。如果某个任务负载超过上阈值，则迁往大核心丛集;掉落到下阈值，则回到小核心丛集。这里的某些参数应该是由OEM厂商决定的，比如说对负载做平均的时间窗口，华为当初定了16ms，而三星则选择了32ms.
这种方案的一大问题是，scheduler事实上完全不清楚，在不同核心之间做线程迁移时，硬件的功耗情况如何。比如说有少量的高负载线程，从大核丛集迁往小核丛集，后又迁回大核。从直觉来看，大核丛集可以在一段时间内休息，还能关掉L2 cache节能。但对核心丛集做重复、高频的开关操作，其实际功耗，可能会比单纯让这些负载一直呆在大核上更高。
AnandTech早年在评测Galaxy Note 4(Exynos 5433)的时候就曾吐槽过GTS，评价软件是big.LITTLE技术的“阿喀琉斯之踵”，严重限制了其潜力。加上当时三星还加了提频机制，降低了迁移的阈值，令功耗问题进一步恶化。另外还有一些问题，比如PELT机制的特性，决定了它对于线程在小核与大核间迁移，有比较久的延迟。
彼时有更多的芯片厂商在这个问题上有过一些探索，比如高通在骁龙810时期推行某种“基于窗口”的系统——这种机制对任务的多个最近历史的非空窗口进行追踪，同时查看近期的最大值，来查看是否有任务会突然需要大量的CPU资源。如此一来，某个线程在空闲、高负载状态之间的切换，所需的等待周期会短很多。
高通这一时期的方案和GTS在很多组成部分上都还是比较类似的，不过的确存在着不少改良，包括基于每瓦性能对线程在大核心之间做迁移，还有对于线程迁移功耗的感知能力等，这些都是原GTS机制所没有的。另外也包括引导CPU频率governor，在做任务迁移后，提升核心效率等。至于骁龙810本身作为一代火龙产品，那也是另一个综合性质的话题了。
高通在big.LITTLE方面的探索，以前还是走在Arm前头的。Arm这一时期的Energy Aware Scheduling(EAS)方案尚未真正实现商用。同期主线内核，EAS并未得到普遍支持。芯片厂商在调度问题上都有各自的魔改解决方案。似乎最晚是到2019年2月，Arm开发者社区发布文章谈到Linux 5.0主线融入了EAS调度方案，这应该算是Arm的又一次重要转向。Android-3.18内核开始，EAS得到支持。
EAS让Linux scheduler对核心之间的功耗/性能区别有感知。EAS以CPU能耗模型，来优化工作负载的调度。对应的能耗模型为scheduler提供CPU拓扑的抽象可视性，基于该能耗模型，EAS也能够预测在某个CPU上执行任务的能耗的影响，决策实现能耗最小化。
另外EAS也和DVFS子系统作了比较紧密的关联——governor也利用负载追踪参数来决策CPU的频率变化。这种程度的关联配合，就让EAS能够估算任务迁移，对于系统能耗的影响，将这方面的能耗加入到迁移决策流程中。这一点前文就已经提到，是早期GTS的一大软肋。
上面这张图是，在Arm Juno r0平台用EAS方案，使用RT-App(一个负载生成器)，主要倾向于考察能耗，并以Hackbench作为性能基准测试。这其中还是能够看到显著差异的，主要表现在能耗上。
Intel与微软的携手尝试
有关Arm的big.LITTLE、DynamiQ不同核心的调度故事篇幅有些太长了，还有很多细节也无法在这篇文章中交代清楚。但整体可从中看出，big.LITTLE为代表的不同核心构成相同处理器的结构，在调度机制上是经过了多代演进的。
Alder Lake的诞生，也需要Intel和微软配合打造“混合架构”处理器的调度机制(虽然更早的Lakefield也已经有了这方面的需求;微软和高通现在应该也有这块的合作)。PC平台以前对于功耗还不像手机那么敏感，但随着Arm开始在PC市场大展身手，尤其苹果M1的问世表明像笔记本这类形态的设备，对低功耗的追求也可以很高。所以Alder Lake的一个重要组成部分就是E-core效率核心。
这一代E-core架构，此前我们已经详细撰文探讨过。它的思路和Arm的顺序执行小核可不一样。E-core(Gracemont)的整数算力与效率甚至比几年前的Skylake还要领先很多。当年Arm的难题现在也摆在了Intel的面前。Intel的解决方案是Intel Thread Director。
不过鉴于Intel和微软公开的信息比较少，我们也无法就同一个层面将其与隔壁家比较，前文的内容也全当是开拓视野了。而且可能Intel与微软的方案，与Arm那边是存在根本差异的。
Intel在本次追加的答疑专场中提到，“以前Windows 10是怎么做的呢?当时是P-core最强大，有游戏要执行时就让P-core来做，有背景(后台)任务要执行时，就让E-core来做——这么做省电。后台的工作有可能是备份资料、扫毒等。这是非常直觉的判断方法。”
我们认为，Windows 10的机制应该也绝对不会这么简单。在Lakefield之时，微软和Intel应该就已经有这方面的合作了。基于Intel对E-core的定位，E-core实际上和Arm那边的小核还是很不一样，而强调其“吞吐”、“多线程”执行效率。E-core不是“弱核”，或者不只是专注于低功耗的概念。
微软Windows内核团队开发经理Mehmet Iyigun此前说：“要做出决策，scheduler需要考虑一些因素，诸如线程优先级、所属应用，以及应用是在前台还是后台。”这段话应该能表现出Windows 10在考察因素方面的单一性。
“直到现在为止，scheduler对于跑在线程上的工作负载，都还是没有可视性的：无论是复制内存、回调循环还是执行复杂计算。” Iyigun说，“如此一来，当高性能核心供不应求时，后续做出的决策就可能不是最优的，因为scheduler不清楚究竟谁最能从高性能核心收益。”
这一例跑的是典型的媒体、内容创作型软件，绿色框表示大部分执行标量指令，蓝色表示大部分执行矢量指令;他们都被放在了P-core;青色表示后台任务，这些线程放到了E-core上
而Windows 11引入了对于Intel Thread Director的支持。需要明确的是，Intel Thread Director主要是处理器这一侧的硬件技术，而不是指操作系统scheduler，也不是一种完整的调度机制。它会监控指令组合、每个核心的当前状态，以及细粒度的相关微架构的观测。据说是Alder Lake为此集成了一个performance monitoring unit单元，通过它来实时监控处理器内核运行情况。操作系统就能利用这些信息做调度决策了。
用Intel工程师的话来说，是操作系统能够获得“hint”，并基于此再做决策，明确某个任务该上P-core还是E-core。Intel Architecture Day上，其客户端架构师Rajshree Chabukswar也提到，“传统的操作系统，会基于有限的信息做出决策，比如前台还是后台。而Thread Director是增加了新的维度。”
Intel在Architecture Day和追加媒体答疑会上都没有仔细说，究竟做哪些考量。这次答疑会上，Intel提到Thread Director“汇报给操作系统的信息很详细，目前这个task已经做到了什么程度、core耗电多少等等，是指令层级的，哪些指令已经在执行的……没有Intel Thread Director之前，不会汇报到这么详细。”
Iyigun则说：“有了Thread Director的反馈，Windows 11的线程scheduler就能更智能地、基于工作负载，来动态挑选最合适的核心，获得最佳效率和性能。即便所有的P-core都处在忙碌状态，只要有新的线程在系统看来更适合放在P-core上，那么P-core上原有的某个线程就会被替换下来。”
这其实也是Intel特别强调的Thread Director的“动态”特性。比如所有P-core均处于忙碌状态，但此时有个需要使用AI指令的AI线程对高性能提出需求。在这种情况下，Thread Director会向操作系统发出一个“hint”。与此同时Thread Director也会去发现，基于相对性能排序，是否存在一些候选线程，可以从P-core移往E-core，让位于AI线程。
多提一句，这种“指令层级”或者基于(现有任务所需的)指令的调度(比如AI指令集对应的任务，应用于P-core)，和前文提到Arm基于核心功耗、算力需求，并设立相应阈值做调度的方式，可能是存在相当大的不同的。当然我们也未知其中全貌。
“这是我们这项技术动态特性的体现，让所有软件任务保持动态性。”说起来，“动态”应该也是Arm那边的目标之一吧，尤其节能、高效对Arm而言很重要。对Intel而言，可能与能效并重(或更重要)的，也在于不能牺牲性能。所以双方在这种混合架构设计理念上，大概还是存在不少微妙差异。
另一点可表现“动态”这一特性的是，如果位于P-core上的某个线程进入回调状态、等待工作出现，那么Thread Director也会将这个情况汇报给操作系统。这个线程也会被迁移到E-core。
Chabukswar事实上还在会上演示某些应用，所有线程在其执行过程中，会经历多个阶段。比如某些时刻矢量线程、AI线程也会进入E-core——这是因为它们在某些阶段会有一些标量指令。“动态特性，就是要将正确的线程，安排到正确的核心上，基于现有执行上下文。”
所以我们从Intel、微软透露的信息可知的是，Alder Lake + Windows 11，实现了硬件级的调度反馈机制，与此同时Windows 11能够基于这种反馈来实现完全“动态”的调度。这里还有一些信息没有提到，比如从硬件层面对一个线程做profile，时延短至30μs，比传统操作系统scheduler给出相同的结果快很多。
另外，Intel的P-core其实还支持超线程，这理论上应该给线程调度增加了难度。现在可知的是，针对某个应用，每个线程会首先考虑占满每个核心，包括P-core和E-core，随后再考虑启用P-core的超线程——据说可以实现相对更高的性能。所以E-core上或许也将能见到一些高性能需求负载。
最后值得一提的是，对于Windows 11而言，应用开发者可以通过新的API来指定其线程的QoS属性，告知scheduler更倾向于P-core还是E-core。微软强调了Windows 11中的各组成部分，比如Edge浏览器就已经应用了EcoQoS API。所以未来“优化好”的软件，理论上能实现更高的效率提升。
另一个很多人关心的重点是，在未来的Alder Lake PC上，Windows 10是否在性能和效率上因此与Windows 11拉开差距。Intel在这个问题上的表态非常模糊。外媒此前有消息说Windows 10未来也会受惠于Thread Director，未知真假(毕竟Windows 11的升级重点之一就是不同核心的调度特性提升)。
其实基于Intel和微软提供的这些信息，我们也拼不出调度策略更完整的版图，只是听Intel举了一些例子;并谈到了Intel Thread Director的部分特点。对此感兴趣的同学还可以前往看一看Intel Architecture Instruction Set Extensions and Future Features文档，其中相关EHFI部分描绘不同的性能级，或许对于理解Thread Director会有帮助。而Intel Thread Director的实际效果如何，还是有待市场和用户去检验的。
免责声明：本文系网络转载，版权归原作者所有。本文所用视频、图片、文字如涉及作品版权问题，请第一时间告知，我们将立即删除内容！本文内容为原作者观点，并不代表本公众号赞同其观点和对其真实性负责。
