| RFC-0255：系統活動管理員 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 定義可運用電源拓撲概念管理平台暫停狀態的元件。 |
| 問題 | |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2024-05-07 |
| 審查日期 (年-月-日) | 2024-08-02 |
摘要
這項 RFC 建議新增名為「系統活動管理員」(SAG) 的核心元件，以管理系統的電量。本文介紹 SAG 的需求、政策，以及實作時使用的流程，以管理系統電源層級。這份 RFC 可視為 RFC-0230：Fuchsia 中的暫停至閒置實作項目的一部分。
目標
- 啟用暫停至閒置狀態的發生時間管理功能。
- 提供暫停相關統計資料，進一步改善日後的電源管理，並監控整個車隊的耗電量。
非目標
- 將特定硬體系統轉換為不同電源狀態，包括但不限於 CPU、GPU、記憶體、網路介面等。
- 導入觸發工作暫停的邏輯，例如
zx_system_suspend_enter。
提振精神
Fuchsia 是通用作業系統，可為多元的硬體和軟體生態系統提供動力。為滿足對電力敏感的軟硬體需求，Fuchsia 必須能夠管理所執行硬體平台的耗電量。包括將 CPU 轉換為低功耗模式、觸發全系統工作暫停、啟動記憶體自我重新整理，以及任何其他省電硬體功能。一組旨在降低耗電量的硬體設定或狀態會歸類為「暫停狀態」。
許多系統都支援多種暫停狀態。每個暫停狀態都有一組硬體狀態、耗電量和恢復延遲 (退出暫停狀態的時間延遲)。每個系統可能在概念上定義相同的暫停狀態 (暫停至閒置)，但對應的硬體設定完全不同。
舉例來說，Fuchsia 可能在兩個 CPU 不同的系統上執行。其中一個 CPU 的耗電量可能比另一個 CPU 低，但兩個系統都可能將轉換至最低耗電量狀態視為進入「暫停至閒置」狀態的作業。
考量這個主題時，平台狀態如下：
- RFC-0230：Fuchsia 中的暫停至閒置定義了暫停至閒置的高階需求和設計。目前 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 quiche@google.com (UI)
- Nick Maniscalco maniscalco@google.com (Zircon 核心)
- 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 (驅動程式架構)
- Suraj Malhotra surajmalhotra@google.com (驅動程式架構)
社交：
我們與電源團隊和子系統擁有者討論了這項設計，他們負責管理核心、驅動程式、驅動程式庫架構、元件架構、產品政策和電源架構。
需求條件
支援暫停轉換的系統必須支援 Fuchsia 產品的使用情境，以及暫停狀態的硬體需求。為妥善協助轉換至暫停狀態，同時維持產品的使用情境，SAG 必須符合下列規定：
- Fuchsia 元件 (包括驅動程式) 必須能在重要作業進行期間，防止轉換為暫停狀態。舉例來說，假設使用者正在觀看影片，裝置不應在影片播放時嘗試暫停系統，否則使用者體驗會不佳。
- 如要啟用以產品為主的停權政策，必須收集並公開停權統計資料。舉例來說，假設某項產品的暫停轉換只能在上次繼續後至少 1 秒觸發，如要讓產品元件支援這項功能，必須能夠計算上次恢復轉換後經過的時間。
SAG 只會負責決定何時轉換。轉換至各暫停狀態的定義和輔助作業，將由實作 SAG 所用
fuchsia.hardware.power.suspend.Suspender通訊協定的元件處理。本 RFC 會延後定義完整通訊協定，但Suspender必須提供下列功能：- 硬體支援的暫停狀態清單。
- 將硬體轉換為暫停狀態。
在這個設計中，SAG 會控管 (或限制) 系統執行程式碼的能力，並由 Fuchsia Suspend HAL (實作上述 Suspender 通訊協定) 將系統轉換為暫停狀態。為配合這個概念，我們做出下列假設：
- 硬體平台是指硬體和軟體系統的集合，可讓運算裝置執行本 RFC 中的程式碼。這通常包括 CPU、記憶體、作業系統，以及這些項目運作所需的其他控制項 (時脈樹狀結構、電源網域等)。這項數據不包含傳統周邊元件，例如微控制器單元、無線電、螢幕控制器、次要儲存空間 (固態硬碟、eMMC) 等。
- 如要支援硬體平台暫停功能，所有產品必須包含電源中介元件。
- 暫停期間，Fuchsia 元件不會在 CPU 上執行，包括 SAG 本身。在微控制器或其他周邊硬體上執行的韌體可能會繼續處理資料。硬體平台進入暫停狀態時，CPU 可能會離線，排程器可能會更新政策，而周邊裝置可能會變更設定。
- Fuchsia 元件必須 (直接或間接) 與電源拓撲整合，才能允許和/或防止轉換至暫停狀態。這個集中式會計機制可讓 SAG 瞭解系統其餘部分的需求，而不必知道這些元件的狀態。
- 未與電源拓撲整合的 Fuchsia 元件「不得」期望不間斷執行。因此，任何需要不間斷執行的元件，都必須考量硬體平台暫停作業的情況，才能執行重要工作 (例如從網路或周邊裝置接收資料)。方法是直接或間接與電源架構互動，詳情請參閱「防止暫停」一文。
- 如果喚醒中斷要求待處理，硬體平台不得暫停。這對所有驅動程式都很重要，因為無論驅動程式與電源架構的互動情形為何，都有機會處理中斷。驅動程式在確認中斷後需要執行更多處理作業時，必須與電源架構互動，以免硬體平台暫停運作。
- SAG 必須提供給驅動程式和熱切元件，這些元件會感知電源狀態，並出現在核心讀取的第一個檔案系統中 (例如 RFC-0167：早期使用者空間啟動程序中的套件的啟動檔案系統)。如果沒有這項功能，電源感知元件就無法設定電源設定，防止系統暫停運作，直到稍後 SAG 可用為止。此外，在暫停轉換期間，較高層級的檔案系統可能會設定為比存在於較低層級檔案系統中的驅動程式更早關機。這會導致電源元件依附關係問題。
- SAG WILL 盡可能使用電源拓撲概念，將硬體平台驅動至最低電源層級。裝置最終是否會進入/停留在最低電量等級，以及停留多久，取決於產品行為和政策、環境條件和使用者行為。
設計
系統活動管理員包含下列部分：
- 電源元件
- 初始化、狀態管理和處理電源電量變更的商業邏輯。
- 提供暫停/恢復相關統計資料存取權的 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 觸發暫停轉換。
在上圖中，媒體播放器元件有一個名為「Playback」的電源元素。「Playback power」元素會明確依附於 Execution State 的電量。Active需要開始播放媒體時，Media Player 元件會要求 Active 電源等級的租用權 Playback，以防止硬體平台暫停。滿足租約後，媒體播放器元件即可執行媒體播放邏輯，不必擔心硬體平台意外暫停。
依執行狀態限制裝置
產品可採用的一項強大模式，是根據硬體平台的執行狀態限制裝置的電量。這可用於將周邊裝置耗電量與硬體平台的暫停狀態繫結。硬體平台轉換為暫停狀態時，驅動程式庫可以關閉裝置電源或變更設定。如果產品需要在硬體平台暫停時關閉特定功能或子系統，以減少耗電量，則適合使用此設定。
音訊範例
建議使用音訊硬體耗電量較高的產品。產品擁有者只希望在硬體平台喚醒時啟動音訊硬體。產品擁有者可以透過電源拓撲，以機會依附元件的形式表示 Execution State 的設定。
在上圖中，音訊驅動程式庫 (圖中稱為「Audio」) 具有名為「Power」的電源元素。音訊驅動程式庫會視 Execution State 的Active電量，決定是否依附於 Execution State。音訊驅動程式庫可以向 Power Broker 要求租用，藉此監控依附元件是否已完成。當 Execution State 轉換為 Active 時，音訊驅動程式的電源租用將會滿足。屆時，音訊驅動程式庫可以執行啟動音訊硬體所需的任何邏輯。反之，當 Execution State 想要將電量從 Active 降低時，音訊驅動程式庫程式的電力租用就會不符合條件。此時，音訊驅動程式庫可以執行邏輯，停用音訊硬體，然後通知 Power Broker 其電源元素已降低電源層級。
處理喚醒中斷
硬體平台暫停後，可透過外部刺激恢復運作。這類外部刺激通常是周邊元件引發的 CPU 中斷。如要正確處理喚醒中斷，預期會發生下列情況：
- 系統會在懸吊系統停用前，預先設定駕駛人的尾流向量。
- 處理中斷時：
- 如果驅動程式庫正在等待中斷的連接埠，核心會排定其中斷處理常式執行緒 (IHT)。
- IHT 或由其通知的其他元件「可能」會建立租約，以防止硬體平台暫停運作。
- 驅動程式會視需要與硬體和/或其他元件通訊，以處理中斷。在此期間，其他元件可能會要求租用。
- 中斷處理完成後，驅動程式會呼叫
zx_interrupt_ack。
處理中斷時，SAG 隨時可以執行，因為核心會恢復硬體平台轉換為暫停時暫停的工作。
儲存空間範例
請參考「依執行狀態限制裝置 」的音訊範例。儲存空間硬體可能與音訊遵循類似模式，在硬體平台暫停時通常會關閉，但硬體平台轉換為暫停或恢復服務以處理喚醒中斷時，也會關閉。如果目前已分頁的元件需要關機並執行清除作業，再暫停作業，可能會導致問題。由於關機作業的順序不具決定性，因此這種簡化設計並不夠用。
如要解決這項缺點，其中一種方法是在轉換期間執行儲存空間驅動程式庫。
在上圖中，名為「Storage」的儲存空間驅動程式庫有兩個電源元素：
- Power 具有 (執行狀態、暫停) 的機會依附元件。當其他電源元素提高
Execution State的電量時，這項依附元件就會滿足。只要儲存空間驅動程式庫在執行狀態啟動電源後持有租約，執行狀態就無法降低電源層級。Suspending這是必要步驟，因為儲存空間驅動程式庫需要監控何時應關閉電源。 - 「喚醒要求」會明確依附於 (執行狀態、暫停)。這項依附元件會強制
Execution State提升功率。儲存空間驅動程式庫會在收到儲存空間要求時，租用這項電源元素。這是必要步驟，因為即使系統其他部分關機，儲存空間硬體仍需供電。
處理系統範圍內的轉場效果
啟動
首次啟動 SAG 時，系統完成啟動程序前不會觸發暫停。處於啟動狀態時，Execution State 電源元素應處於 Active 電源層級，反映硬體平台正在運作，且未嘗試暫停。
在此期間，其他元件可以建立影響 Execution State 的依附元件和租用項目，但 Execution State 在啟動完成前，一律會處於 Active 電源層級。如要退出啟動狀態，必須通知 SAG 代管的 FIDL 服務啟動作業已完成。當系統較高層級可表達電力需求時，預期會使用這項服務，例如在使用者可互動時透過工作階段表達。
暫停/繼續
系統會在Execution State電量達到最低電量Inactive時，要求暫停轉場效果。開始暫停轉換前，SAG 會通知已註冊的接聽者即將暫停。為妥善處理自身、Power Broker 和中斷處理驅動程式庫之間可能發生的競爭情況，SAG 需要下列項目：
- 如果尚未確認喚醒中斷，Fuchsia Suspend HAL MUST 會傳回錯誤。這樣可避免發生競爭條件，導致 SAG 在中斷處理常式有機會要求租約並確認中斷之前執行。
- SAG 不得在暫停要求處理期間變更
Execution State的功率等級。當 SAG 從暫停狀態恢復時，Execution State的功率位準應一律為Inactive。依賴Execution State的裝置會在轉換為暫停狀態之前和期間，立即轉換並維持在適當的電源層級。SAG 會「鎖定」Execution State的電量，方法是延遲處理 Power Broker 要求的電量變更，確保電量維持在特定水準。 - 如果驅動程式庫需要執行後續工作，驅動程式或中斷處理常式必須先取得租約，才能確認中斷。
硬體平台恢復執行作業時，SAG 會收到 Suspender 裝置的回應，指出暫停要求結果。SAG 隨後會將暫停要求結果通知已註冊的監聽器。屆時，聽眾可以要求租用，避免硬體平台暫停服務。詳情請參閱「防止停權」。
此外，暫停要求也可能在轉換前失敗。 這可能是因為有待處理的中斷作業會立即喚醒硬體平台，或是 Fuchsia Suspend HAL 或核心發生其他錯誤。如果暫停要求失敗，SAG 會通知監聽器失敗情形，並等待所有監聽器確認通知。這項設定可讓產品層級的元件要求租約，並變更系統設定，避免重複傳送最終會失敗的暫停要求。
如果沒有接聽程式在恢復轉換期間提高 Execution State 的功率，SAG 會記錄這項失敗。如果接聽裝置當機，或是產品沒有有效的產品體驗 (或產品體驗不完整/仍在開發中)，就可能發生這種情況。
關機
當系統中執行的元件要求關機或重新啟動時，元件管理員會根據能力圖開始終止元件。這會導致問題，因為在 SAG 之前，會終止讓硬體平台無法暫停的元件。這會導致 SAG 在關機期間錯誤觸發停權。
為解決這個問題，負責協調關機的元件 (shutdown-shim 和/或 power-manager) 必須持有租約，讓 Execution
State 維持在 Suspending 電源層級。由於 shutdown-shim 和 power-manager 是重新啟動前最後執行的元件，因此可避免錯誤暫停。
實作
新增這項功能需要進行許多個別變更，並在全面實作完成前，獲得重要子系統的支援。這項程序可細分為下列步驟：
- 基本停權支援
- 「
Execution State」變成「Inactive」時觸發暫停 - 在恢復播放時傳送聽眾通知。
- 連線至恢復通知的接聽器，讓系統保持喚醒狀態。
- 「
- 將所有重要子系統連線至 SAG 介面，因為這些子系統會感知電源狀態。
- 找出最適當的暫停時間。
- 從核心和/或 Fuchsia Suspend HAL 顯示中斷和/或其他喚醒條件的存在。
- 使用核心/Fuchsia Suspend HAL 信號，延遲觸發預期會失敗的暫停要求。
- 持續整合其他可感知暫停的子系統。
效能
對系統效能的整體影響，主要取決於 Power Broker 的效能。大多數 SAG 用戶端會在初始化期間執行一次性呼叫，以設定與未來互動的依附元件，這些互動會由 Power Broker 促成，因此屬於間接互動。監聽 SAG 事件的用戶端會直接影響系統效能，因為用戶端「必須」確認處理繼續和暫停失敗通知。我們應密切監控這些事件處理常式的延遲指標，確保產品能及時處理繼續和暫停失敗問題。最後，Fuchsia Suspend HAL 會回報觸發暫停的延遲時間。我們應監控這項延遲時間，確保暫停作業能在各項產品中及時完成。包括監控延遲時間，以及在暫停失敗時還原暫停要求對效能的影響。
安全性考量
RFC-0250：電源拓撲建立的電源架構定義了電源拓撲的安全模式。SAG 會透過通訊協定能力公開電源元素的存取權。其他電源元素可透過這個通訊協定，依附於 SAG 的電源元素。最終，SAG 安全性取決於元件架構提供的保證，以路由傳送通訊協定能力。
SAG 的通訊協定能力依附於 Fuchsia Suspend HAL 和 Power Broker。如果這些元件出現任何非預期行為，可能會導致 SAG 實作發生錯誤。SAG 必須考量缺少的依附元件和行為異常的依附元件，以減輕連鎖負面影響的可能性。
註冊監聽器的用戶端可能會濫用這項功能。惡意元件可能會未及時確認事件，導致系統無法正常暫停或繼續執行作業。如要避免這類問題，請在回應中設定逾時。
隱私權注意事項
我們預期 SAG 不會收集任何個人識別資訊；不過，SAG 會透過 FIDL 協定和 Inspect 收集並公開從暫停/繼續行為衍生的資料。這項資料會匯總至裝置外系統，供產品擁有者和 Fuchsia 工程師分析。這項實作作業需要經過隱私權審查。
測試
我們會透過一系列整合測試和端對端測試，驗證 SAG 的運作情形。整合測試可確保 SAG 在內部狀態之間轉換，並正確傳送暫停要求。
用戶端可以使用一組測試支援程式庫測試實作項目，這些程式庫會使用 Power Broker 和 SAG，但會移除 Fuchsia Suspend HAL。這個測試支援程式庫可讓用戶端在 SAG 中叫用特定狀態，確保用戶端元件能正確回應這些變更。包括確保適當處理電力等級轉換觸發的所有副作用。如果元件依附於 SAG 的電源元素，完整的測試套件應包含下列情境：
- 沒有電源架構
- 處於初始啟動狀態的 SAG，功率等級已鎖定
Execution State，功率等級ActiveExecution State，功率等級SuspendingExecution State，功率等級Inactive- (如適用) 在重要作業期間不會暫停
說明文件
您需要提供詳盡的文件，說明 SAG 在系統中的角色、設定 (包括產品負責人的期望)、API 模式和測試支援程式庫。說明文件應包含操作 SAG 電源元素的範例和最佳做法，以及如何適當使用其 API。範例應包含上述「設計模式」一節中列出情境的逐步指南。
這份文件應屬於電源架構及其概念的較大文件集。
缺點、替代方案和未知事項
實作這項提案的缺點，是建構在一般電源架構的缺點上。
觸發停權的信號是去中心化的。除非產品擁有者安排元件強制執行此模式，否則沒有任何單一元件能保證會透過這個 API 暫停。從 API 使用的角度來看，這會導致系統行為不明確。舉例來說，如果擁有 Execution State 租約的元件放棄租約，但其他元件仍有租約，SAG 可能不會暫停。元件只會透過向 SAG 註冊監聽器來得知暫停觸發，這會增加複雜度。
如果使用者空間提供恢復延遲時間規定，Fuchsia 應遵守相同規定。如果未提供恢復延遲時間，Fuchsia 應以盡可能最低的恢復延遲時間進入「暫停至閒置」狀態。
由於平台目前只支援一個暫停狀態，因此這項 RFC 並未考量這項需求。
我們尚未找出所有可能的電源控制模式，因此這個設計可能會隨著這些模式的發現而演進。包括但不限於恢復延遲考量、支援更多暫停狀態等。如有需要，這些設計變更將在後續的 RFC 中編碼。