CPU省電的秘密（二）：CStates

前一篇關於EIST的文章中，我們提到了CStates，這裡我們詳細介紹一下它的由來和運行機理。

上一篇文章中我們介紹了EIST，OS在工作任務不重的時候，可以調用硬體提供的介面對CPU進行降頻降壓以節省用電。但是如果不但任務不重，而是無事可干怎麼辦，為什麼不幹脆關掉這個內核呢？

想像一下，我們新建了一個有八個大車間的新工廠，廠房乾淨漂亮，傳送帶筆直乾淨，各個廠房之間有寬闊的道路，到處照明充足，在車間外還有外圍倉儲庫，和總的入廠出廠和後勤支持部門。更妙的是，這裡全部機器人操作，只有你坐在總經理辦公室里，手握一個可以控制各個地方的遙控器。你的最大敵人是需求極度不明確，隨時都有可能變化，為了更大的利益，你會如何安排生產策略呢？聰明的你當然會在需求很大時加大馬力全力生產，以求最大效益。在需求不足時，可以讓有的生產線傳送帶減慢些，以節省不必要的消耗。需求進一步下滑時，你會停掉某個車間的流水線，同時切斷流水線機器人的電源，你還留有後手，在需求回升時隨時可以恢復生產。需求還是很糟糕一段時間後，你會幹脆關掉這個車間，讓機器人都回到倉庫中，關掉車間所有的照明等等的電力，這樣幾乎不會消耗什麼東西了，不過要恢復生產就要費一番時間了。在明確是淡季後，你關掉了幾個相鄰車間，並關閉其共享的道路和後勤部門，清空了附近的倉庫，進一步減低消耗。在做這些事時，你需要仔細衡量各個時機，以在省電和不會被忽然來到的需求弄得焦頭爛額之間尋求平衡，越節省電力，要恢復全力生產就越麻煩，而你必須做到心中有數。

這裡你就是OS（操作系統），工廠是CPU，而車間就是內核（假設八核），倉庫是Cache；各個省電的級別可以映射到不同的CStates（第一個調慢流水線是Pstates），你聰明的抉擇自然歸於OS的電源管理策略了。怎麼樣，是不是很簡單直接呢？

你也許會吃驚於這個低功耗概念是在486DX就部分引入了，遠不是什麼新鮮事。然而，隨著時間的遷移，越來越多更加省電的狀態被引入到最新的CPU中。在深度上，最開始只有C1，接著C2、C3、C5、C6、C7等等陸續得到支持。在廣度上，開始時Thread級別的（HT情況下，一個Core有兩個Thread）,後來加入了Core級別的，在多CPU的系統上還引入的CPU整體的CStates（Package CStates）。在最深的Package CStates下的CPU，耗電幾乎為0了。下面有張簡表我們可以看看各個CPU的支持程度:

操作系統最開始只是簡單的在Idle（空閑）時調用HLT指令從而進入C1。在Windows95開始支持ACPI後，才開始支持其他的CStates。

和上一篇文章一樣，我們還是要強調，OS主導了在整個CStates在的的切換，只有它最了解工作量。同時CStates要工作，硬體，固件和OS三方缺一不可。我們也就從這三個方面介紹它的工作原理。

1. 硬體

Intel CPU是CState可以工作的硬體基礎。它通過一系列寄存器保證固件和OS可以得到足夠的信息，有足夠的手段控制CState的工作模式。下面我們詳細介紹下各個不同的CStates。

· C1

所有的X86 CPU都有個HLT（」Halt」）指令，調用後，CPU會進入idle模式，什麼事也不幹，直到收到中斷。這裡是個絕佳場所可以用來節電，Intel在這裡引入了C1狀態，關閉了時鐘信號（內部bus和APIC除外）。由於時鐘信號驅動內核里絕大多數部件，它的停止，讓這些設備也停止了運行，從而減少了電能消耗。有趣的是HLT指令自從8086開始就有了，這次的功能擴展幾乎不要任何軟體改動就能省電。

在Core 2 Duo（酷睿2）引入了C1E（Enhanced Halt），在關閉時鐘的基礎上調低了電壓，從而更加省電。如果你在固件中打開它，HLT時會自動進入C1E而不是C1。

· C2/C3

C2也是在486DX引入，它增加了一個STPCLK(「Stop Clock」)引腳，這在某種程度上和C1很像，不同點在於，一個是軟體觸發的（C1），一個是硬體觸發的（C2）。後來加入的關閉時鐘發生器的功能讓耗電進一步減少。後面C2E也出現了，C3開始內部的BUS和APIC時鐘也被關閉，這裡不再贅述。

要特彆強調的是，C1，C2和C3下，Cache一致性是得到保證的，從而恢復現場速度也很快。

· C4/C6/C7

C4/C6/C7下，越來越多內部設備的上下文狀態信息（Context）也被封存和凍結，Catch被清空和關閉。如此一來，要恢復現場變得越來越耗時。同時Cache一致性也被破壞，OS需要知道它何時需要清理Cache。

2.固件

前文中已經提到ACPI，這裡不再贅述。CStates的狀態轉換如下圖：

這裡要強調一下，ACPI的C1,C2,C3並不等同於硬體提供的C1,C2,C3,C5..C7。細心的讀者會發現他們個數並不一致。ACPI的CStates是個軟體抽象概念，它認為進入更深的Cstate時會有更大的延時，通常延遲越大功耗對應的Cstate的功耗就越低。APCI規定C0 C1 C2需要保持cache的一致性（要保證CPU cache中的數據一定要是最新的數據），C3以及後續的state就沒有這個要求了。C0和C1必須支持，而C2/C3就是可選項了。如此一來，固件就有責任將ACPI的CStates映射到合適的硬體的CStates上來。通常C0，C1,C2/C3基本一致(硬體C3和C2基本二選一)，而硬體的C4到C7我們都會映射到ACPI C3上了（ACPI C3不一定唯一，後面有介紹）。

要完成基本的CStates的支持固件應該含有以下步驟：

I. 打開關閉CStates

BIOS可以通過CPUID function 5 來檢查 CPU是否支持Cstate，以及支持哪些Cstate（C1 C1E C3 C6 C7），支持的最大的Cstate也可以通過MSR去設定，默認情況下增強型Cstate以及IO MWAIT Redirection是不支持的，固件要根據系統的需求決定是否開啟支持該功能的寄存器。

II. 初始化

硬體提供我們兩種方式進入CStates（除了C1）：一個IO埠或者MWAIT指令。關於MWAIT，這裡不再展開討論，只需要知道MWAIT的方式通常延遲更小，因為不需要做耗時的IO操作。這裡我們要根據用戶選擇或者預設，開啟或者關閉MWAIT的支持。

III. 填寫各種ACPI tables

1. _OSC & _P.DC

_0SC(Operating System Details) & _PDC(Processor Driver Capabilities)在功能上比較接近，基本上供OSPM調用和BIOS傳遞一些關於Cstate Pstate Tstate是否支持，以及支持的程度和實現方式的一些設定，BIOS可以依據OSPM的參數回報相應的ACPI Structures。

2. _CST

_CST 彙報給OSPM的有關該平台CPU所支持的C-state的信息。它的格式如下所示：

CSTPackage : Package ( Count , CState ,…, CState )

其中Count表示所支持的Cstate的個數

CState: Package ( Register , Type , Latency , Power )

Register表示OSPM調整C-state的方式，Type表示CState的類型（1=C1, 2=C2, 3=C3)。Latency表示進入該Cstate的最大的延遲， Power表示在該Cstate時的功耗（單位是毫瓦）。下面是個樣例，這個CPU支持4個Cstate,其中C1使用FFixedHW的方式訪問，其它3個Cstate都是通過IO方式。

Name(_CST, Package()

{4,Package(){ResourceTemplate(){Register(FFixedHW, 0, 0, 0)}, 1, 20, 1000},Package(){ResourceTemplate(){Register(SystemIO, 8, 0, 0x161)}, 2, 40, 750},Package(){ResourceTemplate(){Register(SystemIO, 8, 0, 0x162)}, 3, 60, 500},Package(){ResourceTemplate(){Register(SystemIO, 8, 0, 0x163)}, 3, 100, 250}})

3. _CSD

C-State Dependency 用於向OSPM提供多個Thread（邏輯Core）之間Cstate的依賴關係。比如在一個Dual Core的平台上，每顆核可以獨立運行C1但是如果其中一個核切換到C2，另一個也必須要切換到C2，這時就需要在_CSD中提供這部分信息。

上面的邏輯通過程序看可能會更加直觀。大家可以訪問在Github上的Minnow3項目的源程序。代碼在tianocore/edk2-platforms

3.OS

OS在收集到了各個ACPI CStates的耗電和延時數據後，會綜合考慮遷移到各個狀態的代價，而這些是一個叫做電源策略管理器（power policy manager）的模塊來管理，在用戶選擇了不同的運行場景（可以調用powercfg.exe查看修改）情況下，根據目前工作量來調用processr.sys，這是個通用驅動，它再調用不同的CPU廠商的特有驅動來切換，Intel的EIST驅動是intelppm.sys，

現在不但各個操作系統利用CStates來省電，甚至在固件的短短運行周期里也會在內核不工作時使其進入Cstate。有興趣的人可以查看EDKII的CPU代碼，其通過一個PCD來控制Idle時是Busy Idle, HLT還是更深的Cstate。

其他CPU電源管理文章：

CPU省電的秘密（一）：EIST - 知乎專欄

睿頻：榨乾CPU所有的潛力（CPU電源管理系列番外篇） - 知乎專欄

歡迎大家關注本專欄和用微信掃描下方二維碼加入微信公眾號"UEFIBlog"，在那裡有最新的文章。同時歡迎大家給本專欄和公眾號投稿！

用微信掃描二維碼加入UEFIBlog公眾號