| RFC-0255：系統活動控管器 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 定義可利用電源拓撲概念管理平台暫停狀態的元件。 |
| 問題 | |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2024-05-07 |
| 審查日期 (年-月-日) | 2024-08-02 |
摘要
這份 RFC 建議新增名為 System Activity Governor (SAG) 的核心元件，用於管理系統的電源等級。本文件將介紹 SAG 的相關規定、政策和實作流程，協助您管理系統的電源等級。這個 RFC 可視為 RFC-0230：Fuchsia 中的 Suspend-To-Idle 實作項目的一部分。
目標
- 啟用管理功能，以便在發生暫停待命時執行。
- 提供有關暫停的統計資料，以便日後進一步改善電力，並監控車隊的耗電量。
非目標
- 實作特定硬體系統的轉換作業，轉換至不同的電源狀態，包括但不限於 CPU、GPU、記憶體、網路介面等。
- 實作邏輯，觸發工作暫停，例如
zx_system_suspend_enter。
提振精神
Fuchsia 是通用作業系統，旨在為硬體和軟體的多元生態系統提供動力。為了滿足對電力敏感的硬體和軟體需求，Fuchsia 必須能夠管理其所執行的硬體平台耗電量。這包括將 CPU 轉換為省電模式、觸發系統層級工作暫停、啟用記憶體自動重新整理，以及任何其他省電硬體功能。為了降低耗電量，一組硬體設定或狀態會歸類為「暫停狀態」。
許多系統都支援多個暫停狀態。每個暫停狀態都有一組硬體狀態、電力使用量和恢復延遲時間 (退出暫停狀態的時間延遲)。每個系統可能會定義相同的暫停狀態概念 (暫停至閒置)，並對應至完全不同的硬體設定組合。
舉例來說，Fuchsia 可能會在兩個 CPU 不同的系統上執行。一個 CPU 可能支援的電源狀態耗電量低於另一個 CPU；不過，兩個系統都可能將轉換為最低電源狀態視為進入「暫停至閒置」狀態的作業之一。
在討論這個主題時，平台的狀態如下：
- RFC-0230：Fuchsia 中的 Suspend-To-Idle 定義了 Suspend-to-Idle 的高階需求和設計。目前，這是 Fuchsia 平台支援的唯一暫停狀態。
- RFC-0250：電源拓樸定義了電源拓樸，可支援 Fuchsia 中日後的電源管理系統。
- 另一個 RFC 會定義在執行階段管理電源拓樸的元件：Power Broker。
- 系統必須解讀來自各個子系統的各種信號，才能協調轉換至「暫停至閒置」狀態。
如要使用 RFC-0250：電源拓樸實作 RFC-0230：在 Fuchsia 中執行暫停待命，就必須建立實作政策的元件，以便管理轉換為暫停待命的作業：系統活動控管器。
相關人員
協助人員：
Adam Barth abarth@google.com
審查者：
- Aidan Wolter awolter@google.com (軟體組合)
- Andres Oportus andresoportus@google.com (平台驅動程式)
- Gary Bressler geb@google.com (元件架構)
- Gurjant Kalsi gkalsi@google.com (平台驅動程式)
- Harsha Priya N V harshanv@google.com (驅動程式架構)
- Justin Mattson jmatt@google.com (驅動程式架構)
- Kyle Gong kgong@google.com (Power)
- Mukesh Agrawal (UI) quiche@google.com
- Nick Maniscalco maniscalco@google.com (Zircon Kernel)
- Onath Dillinger claridge@google.com (Power)
諮詢：
- Alice Neels neelsa@google.com (UI)
- David Gilhooley dgilhooley@google.com (元件架構)
- Didi She didis@google.com (Power)
- Eric Holland hollande@google.com (Power)
- Filip Filmar fmil@google.com (UI)
- Guocheng Wei guochengwei@google.com (Starnix)
- HanBin Yoon hanbinyoon@google.com (平台驅動程式)
- John Wittrock wittrock@google.com (軟體提交)
- Novin Changizi novinc@google.com (Driver Framework)
- Suraj Malhotra surajmalhotra@google.com (驅動程式架構)
社會化：
我們已與負責管理核心、驅動程式、驅動程式庫程式架構、元件架構、產品政策和電源架構的電源團隊和子系統擁有者討論這項設計。
需求條件
支援轉換至暫停狀態的系統必須支援 Fuchsia 產品的用途，以及暫停狀態的硬體需求。為在維持產品用途的同時，妥善促進轉換至暫停狀態，SAG 必須符合下列規定：
- Fuchsia 元件 (包括驅動程式) 必須能夠在進行重要作業時，防止轉換作業暫停。舉例來說，假設使用者正在觀看影片，裝置不應在播放影片時嘗試暫停系統，否則使用者會獲得不佳的體驗。
- 如要啟用以產品為依據的停權政策，您必須收集並公開停權統計資料。舉例來說，假設某項產品的暫停轉換只能在前一次的繼續後至少 1 秒後觸發。為了讓產品元件支援這項功能，必須能夠計算上次繼續轉換作業以來的時間。
SAG 只負責決定何時進行轉換。定義及促進轉換至各個暫停狀態的作業，將由實作 SAG 使用的
fuchsia.hardware.suspend.Suspender通訊協定的元件處理。本 RFC 會延後定義完整的通訊協定，但Suspender必須提供下列功能：- 列出硬體支援的暫停狀態。
- 將硬體轉換為暫停狀態。
在這個設計中，SAG 會充當系統執行程式碼的能力的調節器 (或限制器)，而這項功能是由 Fuchsia 暫停 HAL (實作上述 Suspender 通訊協定) 來執行，以便將系統切換至暫停狀態。為了配合這個概念，我們做出以下假設：
- 「硬體平台」是指硬體和軟體系統的集合，可讓運算裝置執行此 RFC 中的程式碼。這通常包括 CPU、記憶體、作業系統，以及這些運作所需的其他控制項 (時脈樹狀結構、電源網域等)。這項數據明確「不」包含傳統周邊元件，例如微控制器單元、無線無線電、螢幕控制器、次要儲存裝置 (固態硬碟、eMMC) 等。
- 所有希望支援硬體平台暫停功能的產品，都「必須」包含電源仲介元件。
- 在暫停期間，Fuchsia 元件 (包括 SAG 本身) 不會在 CPU 上執行。在微控制器或其他周邊硬體上執行的韌體「可能」會繼續處理資料。硬體平台進入暫停狀態時，CPU 可能會離線，排程器可能會更新其政策，周邊裝置可能會變更設定。
- Fuchsia 元件「必須」與電源拓撲 (直接或間接) 整合，才能允許和/或防止轉換處於暫停狀態。這個集中式記帳機制可讓 SAG 瞭解系統其他部分的需求，而不需要知道這些元件的狀態。
- 未與電源拓撲整合的 Fuchsia 元件不得預期不間斷執行。因此，任何預期不中斷執行作業的元件 (例如從網路或周邊接收資料)，都必須在「防止暫停」一文所述的其中一種方法中，直接或間接地與電源架構互動，以便處理硬體平台暫停問題。
- 在喚醒中斷待處理期間，硬體平台「不得」暫停。這對所有驅動程式都很重要，因為無論與電源架構的互動方式為何，驅動程式都有機會處理中斷。在確認中斷後需要進行更多處理的驅動程式「必須」與電源架構互動，以免硬體平台進入暫停狀態。
- 對於會察覺電力的驅動程式和急切元件，以及在核心讀取的第一個檔案系統中顯示的 SAG，必須提供這些元件 (例如 RFC-0167：早期使用者空間引導程序中的套件 中的啟動檔案系統)。否則，電源感知元件將無法設定電源設定，導致系統在 SAG 可用之前無法進入休眠狀態。此外，在暫停轉換期間，較高層級的檔案系統可能會設定為比較低層級檔案系統中的驅動程式更早關機。這會導致電源元件依附元件問題。
- 在可行的情況下，SAG 會使用電源拓撲概念，將硬體平台的耗電量降到最低。最終，裝置進入/停留在這個最低電量等級的時間長短，取決於產品行為和政策、環境條件和使用者行為。
設計
系統活動控管器由下列部分組成：
- 電源元素
- 初始化、狀態管理和電量等級變更的商業邏輯。
- 提供有關暫停/繼續執行統計資料存取權的 FIDL 服務。
- FIDL 服務，可讓用戶端保持硬體平台運作，並收到暫停/繼續運作轉換的通知。
FIDL 服務的確切定義會延後至 API 審查/校正工作階段。
電源拓撲
如要瞭解電源拓撲圖表慣例，請參閱 RFC-0250：電源拓撲。
SAG 會建立及管理電源元素 Execution State，代表硬體平台執行程式碼的能力。這個電源元素會匯總其他元件的信號，以決定何時應嘗試暫停轉換。
透過建立電源元素，SAG 可讓其他元件執行以下操作：
- 只要硬體平台持有明確聲明，就提高執行狀態的電源等級
- 說明為何硬體平台應透過電源元件及其依附元件鏈結繼續執行程式碼
- 保留機會主義宣稱，回應執行狀態的變更。這也讓 SAG 實作能夠產生副作用，以回應
Execution State的每個依附項目的電源等級變更。 - 最重要的是，RFC-0250：電源拓撲規定電源元素會趨向最低電源等級。因此，在沒有任何依附電源元素處於啟用狀態時，硬體平台的執行狀態自然會受到規範。
執行狀態
這個電源元素會盡可能對應硬體平台執行程式碼的能力。支援 3 種電量等級：
- 運作中
- 暫停中
- 已停用
當硬體平台正常運作時，這個元素應會處於 Active 電源等級。在 Inactive 電源等級時，硬體平台應處於暫停狀態，或積極嘗試轉換至暫停狀態。此時，只有裝置中不支援電源或不受電源影響的部分才應執行。如要進一步瞭解這個設計模式，請參閱「依執行狀態限制裝置」。如要進一步瞭解觸發暫停/重新啟用資源的時間和方式，請參閱「暫停/重新啟用」。
Suspending 電量等級介於 Inactive 和 Active 電量等級之間。這個電源層級的用意在於分離電源依附元件，這些元件「僅」允許在硬體平台執行時執行，以及在硬體平台在暫停狀態和執行狀態之間 (無論方向為何) 轉換時「可能」需要執行的元件。如需瞭解這項區別的實用性，請參閱下方的儲存空間範例。
設計模式
防止暫停
為避免硬體平台進入暫停狀態，元件可以建構電源元素，該元素對 Execution State 具有明確的依附性。
請考慮使用具備媒體播放器功能的產品。產品擁有者希望媒體播放功能可防止硬體平台暫停，以便支援持續音樂播放。為了支援這項功能，管理播放狀態的元件可以建立對 Execution
State 的斷言依附元件，以防止 SAG 觸發暫停轉換。
在上圖中，Media Player 元件含有名為 Playback 的電源元素。播放電源元素對 Execution State 的 Active 電源等級有明確的依附元件。當需要開始媒體播放時，Media Player 元件會要求 Active 的 Playback 電源等級租約，以免硬體平台進入休眠狀態。租約滿期後，Media Player 元件就能執行媒體播放邏輯，不必擔心硬體平台會意外暫停。
依執行作業狀態限制裝置
產品可採用的一種強大模式，是根據硬體平台的執行狀態限制裝置的電源等級。這可用於將周邊裝置的耗電量與硬體平台的暫停狀態連結。當硬體平台轉換為暫停狀態時，驅動程式庫可以關閉裝置或變更其設定。如果產品希望在硬體平台休眠時關閉特定功能或子系統，以減少耗電量，這類設定可能就很實用。
音訊示例
考慮使用耗電量高的音訊硬體產品。產品擁有者只想在硬體平台喚醒時啟用音訊硬體。產品擁有者可以使用電源拓撲來表示此設定，並在 Execution State 上加入機會主義依附元件。
在上圖中，音訊驅動程式庫 (在圖中稱為 Audio) 包含名為 Power 的電源元素。音訊驅動程式庫會在 Execution State 的 Active 電量等級上，有一個機會主義依附元件。音訊驅動程式庫可以向 Power Broker 要求租用權，藉此監控其依附元件的履行情形。當 Execution State 轉換為 Active 時，音訊驅動程式庫對電源的租用權就會滿足。屆時，音訊驅動程式庫就能執行啟用音訊硬體所需的任何邏輯。相反地，當 Execution State 想要從 Active 降低電量等級時，音訊驅動程式庫程式的電源租用權就會變成未滿足。此時，音訊驅動程式庫可以執行邏輯，在通知 Power Broker 其電源元件已降低電源等級之前，先停用音訊硬體。
處理喚醒中斷
硬體平台暫停時，可能會因外部刺激而恢復。這類外部刺激通常是 CPU 中斷的形式，由其中一個周邊元件觸發。如要妥善處理喚醒中斷，應會發生下列情況：
- 驅動程式的喚醒向量會在暫停前設定。
- 處理中斷時：
- 如果驅動程式庫正在等待中斷埠，則其中斷處理常式執行緒 (IHT) 會由核心排程。
- IHT 或其他收到通知的元件「可能」會建立租約，以阻止硬體平台暫停。
- 驅動程式會根據處理中斷的要求，與硬體和/或其他元件通訊。在此期間，其他元件可能會要求租用權。
- 中斷處理作業完成後，驅動程式會呼叫
zx_interrupt_ack。
在處理中斷時，SAG 隨時可以執行，因為核心會在硬體平台轉換為暫停狀態時，恢復先前暫停的任務。
儲存空間範例
請參考「依執行狀態限制裝置 」一文中的音訊範例。雖然儲存空間硬體可能會遵循與音訊類似的模式，也就是在硬體平台暫停時通常會關閉，但在硬體平台轉換為暫停或恢復服務喚醒中斷時，也會關閉。如果目前分頁的元件需要在暫停前關閉並執行清理作業，就可能會發生問題。由於關機作業的順序並非確定性的，因此這項簡化設計是不夠的。
解決這個缺點的方法之一，是允許儲存空間驅動程式庫在轉換期間執行。
在上圖中，儲存空間驅動程式庫 (稱為 Storage) 有兩個電源元件：
- Power 具有 (執行狀態、暫停) 的機會依附元件。當其他電源元素提高
Execution State的電源等級時，就會滿足這項依附元件。只要儲存空間驅動程式庫在執行狀態升級至Suspending後保留 Power 的租約，執行狀態就無法降低其電源等級。這項資訊是儲存空間驅動程式庫需要的，可讓驅動程式監控何時應關機。 - 喚醒要求對 (執行狀態、暫停) 有明確的依附元件。這項依附元件會強制
Execution State提高其電力等級。儲存空間驅動程式庫會在收到儲存空間要求時，租用這個電源元素。這項設定是必要的，因為即使系統的其他部分正在關機，儲存硬體也能繼續開機。
處理系統層級轉換
啟動程序
當 SAG 首次啟動時，系統必須完成啟動程序，才會觸發暫停作業。在這個啟動狀態中，Execution State 電源元素應處於 Active 電源等級，以反映硬體平台正在運作，而非嘗試暫停的實際情況。
在此期間，其他元件可以建立會影響 Execution State 的依附元件和租用權；不過，Execution State 一律會維持在 Active 電源等級，直到啟動程序完成為止。為了退出開機狀態，必須通知由 SAG 代管的 Fidl 服務，指出開機已完成。系統較高層級可表達其電源需求時，就應使用這項服務，例如在使用者互動期間的工作階段。
暫停/繼續
當 Execution State 電量等級為 Inactive (最低電量等級) 時，系統會要求暫停轉換。在開始暫停轉換之前，SAG 會通知已註冊的事件監聽器，即將發生暫停事件。為妥善處理自身、Power Broker 和中斷處理驅動程式庫之間的潛在競爭，SAG 需要以下項目：
- 如果喚醒中斷未收到確認，Fuchsia 暫停 HAL 必須傳回錯誤。這樣可避免在中斷處理程序有機會要求租用權並 ACK 中斷之前，SAG 就會執行的競爭狀態。
- 在暫停要求進行期間，SAG「不得」變更
Execution State的電源等級。當 SAG 從暫停狀態恢復時，Execution State的電源等級應一律為Inactive。依賴Execution State的裝置會在即將進入休眠狀態前後，轉換並維持適當的電源等級。SAG 會「鎖定」Execution State的電源等級，藉此延遲處理 Power Broker 要求的電源等級變更，以確保電源等級不會變更。 - 如果驅動程式庫需要在之後執行工作，則驅動程式或中斷處理常式「必須」在回應中斷之前取得租用權。
當硬體平台恢復執行時，SAG 會收到 Suspender 裝置的回應，指出暫停要求的結果。接著，SAG 會通知已註冊的聽眾暫停要求的結果。屆時，監聽器可以要求租用權，以阻止硬體平台暫停。詳情請參閱「避免帳戶遭停權」。
在轉換發生之前，暫停要求也可能會失敗。這可能是因為有待處理的會立即喚醒硬體平台的中斷，或是 Fuchsia 暫停 HAL 或核心中的其他錯誤。當暫停要求失敗時，SAG 會通知事件監聽器發生失敗，並等待所有事件監聽器確認通知。這項設定可讓產品層級元件要求租用權，並變更系統設定，以免重複傳送最終會失敗的暫停要求。
如果在繼續轉換期間，沒有任何監聽器提高 Execution State 的電源等級，SAG 就會記錄這項失敗。當事件監聽器發生當機，或是產品沒有有效 (或尚未完成/正在開發) 的產品體驗時，就可能發生這種情況。
關機
當系統中執行的元件要求關機或重新啟動時，元件管理員會開始根據能力圖表終止元件。這會導致以下問題：會讓硬體平台無法暫停的元件會在 SAG 之前終止。這會導致 SAG 在關機期間誤觸觸發暫停功能。
為解決這個問題，負責協調關機作業的元件 (shutdown-shim 和/或 power-manager) 必須保留租約，讓 Execution
State 維持在 Suspending 電源等級。由於 shutdown-shim 和 power-manager 是重新啟動前最後仍在執行的元件，因此這可避免誤掛起。
實作
如要新增這項功能，必須先完成許多個別變更，並獲得重要子系統的支援，才能完成完整導入作業。這項程序可分為以下步驟：
- 基本停權支援服務
- 當
Execution State變成Inactive時觸發暫停 - 在繼續播放時傳送聽眾通知。
- 連結接聽器，以便接收可讓系統保持運作的繼續執行通知。
- 當
- 當所有關鍵子系統都變成電源感知型時，請將這些子系統連接至 SAG 介面。
- 最佳化暫停時間。
- 公開中斷和/或其他喚醒條件是否存在於核心和/或 Fuchsia 暫停 HAL。
- 使用核心/Fuchsia 暫停 HAL 信號，延遲觸發預期會失敗的暫停要求。
- 持續整合其他支援暫停的子系統。
成效
對系統效能的整體影響，很大程度上取決於 Power Broker 的效能。大多數 SAG 用戶端會在初始化期間執行一次性呼叫，藉此設定依附元件，讓日後的互動以間接方式進行，並由 Power Broker 協助處理。監聽 SAG 事件的用戶端會直接影響系統效能，因為他們「必須」確認處理暫停和暫停失敗通知。我們應密切監控這些事件處理常式的延遲指標，確保可及時處理各產品的暫停和暫停失敗問題。最後，Fuchsia Suspend HAL 會回報觸發暫停作業的延遲時間。我們應監控這項延遲時間，確保各產品的暫停作業能及時完成。這包括監控暫停要求發生失敗時，反轉暫停要求的延遲和效能影響。
安全性考量
RFC-0250：電源拓撲建立的電源架構定義了電源拓撲的安全性模型。SAG 會透過通訊協定能力，提供對電源元件的存取權。存取這個通訊協定可讓其他電源元素依附 SAG 的電源元素。最終，SAG 安全性會依賴元件架構提供的保證，以便轉送通訊協定能力。
SAG 的通訊協定能力依附元件為 Fuchsia 暫停 HAL 和電源仲介器。如果這些元件出現任何與預期行為不同的情形，就可能導致 SAG 實作出現異常行為。SAG 需要考量缺少和異常的依附元件，以減輕可能發生的連鎖負面效應。
註冊事件監聽器的用戶端可能會濫用這項功能。惡意元件可能會在不及時確認事件，導致無法適當暫停或恢復。您可以為回應設定逾時值，避免這類問題。
隱私權注意事項
我們預期 SAG 不會收集任何個人識別資訊；不過，SAG 會透過 FIDL 通訊協定和 Inspect 收集及公開因暫停/繼續執行行為而產生的資料。這些資料會在裝置外系統中匯總，供產品擁有者和 Fuchsia 工程師進行分析。這項作業需要進行隱私權審查。
測試
我們會透過一系列整合測試和端對端測試來測試 SAG。整合測試會確保 SAG 在內部狀態之間的轉換，並正確傳送暫停要求。
用戶端可以使用一組測試支援程式庫來測試其實作內容，這些程式庫會使用 Power Broker 和 SAG，但會移除 Fuchsia 暫停 HAL。這個測試支援程式庫可讓用戶端在 SAG 中叫用特定狀態，確保用戶端元件可正確回應這些變更。這包括確保系統能妥善處理所有因電量層級轉換而觸發的副作用。針對依賴 SAG 電源元素的元件，完整的測試套件應包含下列情境：
- 無電源架構
- 在初始啟動狀態下，使用鎖定的電源等級進行 SAG
Execution State，電量為ActiveExecution State，電量為SuspendingExecution State，電量為Inactive- (如適用) 在重要作業期間不暫停
說明文件
您需要提供詳細的說明文件，說明 SAG 在系統中的角色、設定 (包括產品擁有者預期的內容)、API 模式和測試支援程式庫。說明文件應提供操控 SAG 電源元素和適當使用 API 的範例和最佳做法。範例應包含上述「設計模式」一節中列出的情況的逐步指南。
這份文件應是電源架構及其概念的更大文件集的一部分。
缺點、替代方案和未知事項
實作這項提案的缺點，是建立在電源架構的一般缺點之上。
觸發暫停的系統信號是去中心化的。除非產品擁有者將元件整理好，以便強制執行此模式，否則沒有任何單一元件可保證此 API 會發生暫停情形。從 API 使用角度來看，這會導致系統行為不明確。舉例來說，當具有 Execution State 租約的元件放棄租約時，如果其他元件有租約，SAG 可能不會暫停。元件只有在透過 SAG 註冊監聽器時，才會知道觸發了暫停作業，這會增加複雜度。
RFC-0230：Fuchsia 中的 Suspend-To-Idle 指出以下事項：
如果使用者空間提供暫停延遲要求，Fuchsia 應遵循相同的規定。如果未提供繼續時間，Fuchsia 應以盡可能縮短的繼續時間進入 Suspend-To-Idle 狀態。
由於平台目前只支援一個暫停狀態，因此本 RFC 不會考慮這項要求。
我們尚未找出驅動程式和現場硬體的所有可能電源控制模式，因此這項設計可能需要隨著這些模式的發現而演進。這包括但不限於恢復延遲考量、支援更多暫停狀態等。這些設計變更會視需要在後續 RFC 中編碼。