不裝Win11嗎？Win10對你的CPU可能不夠友好

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的實際效果如何，還是有待市場和用戶去檢驗的。

責編：Luffy Liu