RFC-0255：系統活動管理者

RFC-0255：系統活動管理者
狀態已接受
領域
  • 電源
說明

定義使用電源拓撲概念管理平台暫停狀態的元件。
問題
毛皮變化
  • 1044213
作者
審查人員
提交日期 (年-月-日)2024-05-07
審查日期 (年-月-日)2024-08-02

編輯此 RFC

編輯 RFC 中繼資料

摘要

此 RFC 建議新增一個名為「系統活動管理」(System Activity Governor，SAG) 的核心元件 控制系統功率。本文件將說明 將 SAG 及其政策及其導入流程用於 以及系統功率管理這個 RFC 可做為 RFC-0230: Pause-Idle in Fuchsia。

目標

  • 啟用管理暫停至閒置的時間點管理。
  • 提供停權統計資料，供日後進一步改善電力與 監控機群全體人員的耗電量

非目標

  • 實作特定硬體系統至不同電源狀態的轉換 包括但不限於 CPU、GPU、記憶體和網路介面等
  • 實作邏輯來觸發工作暫停運作，例如：zx_system_suspend_enter。

提振精神

Fuchsia 是基於各種目的而設計的一般作業系統。 生態系統滿足電源敏感度的需求 因此 Fuchsia 必須能夠 的硬體平台包括執行下列操作： 將 CPU 轉換至低耗電模式、觸發整個系統的工作暫停情形， 啟動記憶體自我重新整理，以及任意數量的省電硬體 接著介紹網際網路通訊層 包括兩項主要的安全防護功能一組硬體配置或狀態，以降低耗電量 消費會歸入暫停狀態的概念中。

許多系統支援多種暫停狀態。每個暫停狀態都有一組 硬體狀態、電源用量和恢復延遲時間 (退出 暫停狀態)。每個系統可能會在概念中定義相同的暫停狀態 對應至完全不同的硬體組合 (暫停至閒置) 儲存空間設定

例如 Fuchsia 可能在搭載不同 CPU 的兩個系統上執行。一個 CPU 可支援電源狀態，但耗電量高於另一個狀態； 然而，這兩個系統都可能會考慮一次轉換到最低功率狀態 部分操作而得進入「暫停使用」狀態。

思考這個主題時，平台的狀態如下：

  • RFC-0230：適用於 Fuchsia 的 Suspend-To-Idle 定義了高階要求。 「停權至閒置狀態」的設計這是目前唯一的暫停狀態 獲得全面支援
  • RFC-0250：Power Topology 定義了長期發展的功率拓撲 管理 Fuchsia 的電費管理系統。
  • 獨立的 RFC 定義了管理電源拓撲的元件 執行時：Power Broker
  • 必須解讀不同子系統的多種信號以協調 切換至閒置狀態。

如要實作 RFC-0230: Suspend-To-Idle in Fuchsia RFC-0250：電源拓撲，這是實作政策管理的元件 需要建立「暫停使用」的轉換作業：系統活動管理者。

相關人員

講師：

Adam Barth abarth@google.com

審查者：

諮詢：

社交功能：

我們與管理團隊的電力團隊和子系統擁有者討論了這項設計 核心、驅動程式、驅動程式庫架構、元件架構、產品政策和 電源架構。

需求條件

支援暫停轉換的系統必須支援 Fuchsia 產品以及暫停狀態的硬體需求。目的地： 妥善促進轉場效果，同時維護 銷售產品，SAG 必須符合下列規定：

  1. Fuchsia 元件 (包括驅動程式) 必須能防止轉換 因此在執行重要作業時 暫停服務就會暫停運作舉例來說 也就是使用者觀看影片時的運作方式不得嘗試透過裝置 在影片播放時暫停系統；否則，使用者 使用體驗不佳
  2. 如要啟用以產品為準停權政策，停權相關統計資料 必須加以收集和公開。舉例來說，假設產品 您只能在 先前的履歷為了讓產品元件支援這項功能 ，必須能夠計算從上次履歷轉換以來經過的時間。

  3. SAG 將只負責判斷轉換「時機」。 定義及達成每個暫停狀態的轉換。 由實作 SAG 使用的 fuchsia.hardware.suspend.Suspender 通訊協定。參閱 RFC 規範 定義完整的通訊協定，但 Suspender「必須」提供下列資料： 功能：

    • 列出硬體支援的暫停狀態。
    • 將硬體轉換為暫停狀態。

就本設計而言，SAG 就像政府或限制人員，負責評估系統能否 執行由 Fuchsia 暫停 HAL (實作 上述 Suspender 通訊協定)，藉此將系統轉換為暫停。 為配合這個概念，我們提出以下假設：

  • 「硬體平台」是指收集軟硬體 讓運算裝置執行此 RFC 中的程式碼這個 通常包含 CPU、記憶體、作業系統和其他控制項 (時鐘樹、電力域等) 這些元素才能正常運作。這個 明確「不」包含傳統週邊裝置，例如 微控器單元, 無線無線電, 螢幕控制器, 次要儲存空間 (固態硬碟、eMMC) 等
  • 凡是要宣傳的產品，都必須包含電源代理元件 支援硬體平台停權
  • 停權期間， Fuchsia 元件無法在 CPU 上執行 就是 SAG 本身在微控制器或其他控制器上執行的韌體 週邊裝置可繼續處理資料。硬體平台 進入暫停狀態，CPU 「可」離線，排程器可 更新政策和周邊裝置「可」變更設定。
  • Fuchsia 元件「必須」直接 (直接或間接) 整合 用於允許及/或避免轉換進入暫停狀態。如此一來 SAG 可透過會計機制瞭解系統的其他部分 而不必知道這些元件的狀態
  • 未整合電源拓撲的 Fuchsia 元件「不得」 不受干擾您需要使用任何 執行不中斷的執行作業，以便執行重要工作 (例如接收資料) 而非由網路或週邊裝置發出的) 等 以其中一種方法直接或間接與電源架構互動 一文中所述的防止停權一節。
  • 在喚醒中斷情形發生時，硬體平台「不得」暫停 待處理。這對所有司機而言都很重要，這樣他們才有機會 服務中斷，無論使用者與 這個架構的重點在於處理中斷後，需要執行更多處理作業的驅動程式 「必須」與電源架構互動，以避免硬體平台 停權。
  • SAG「必須」適用於具備能力感知能力的駕駛和熱力元件 存在於核心讀取到的第一個檔案系統中 (例如啟動檔案系統 來自 RFC-0167：早期使用者空間中的套件 Bootstrapping)。如果沒有這項功能 電源感知功能無法設定能 系統停權，直到 SAG 推出為止。此外，在 暫停轉場效果 上層檔案系統可能會設定 會比較低層級檔案系統中的驅動程式更早關機。 這會導致電源元素依附元件問題。
  • SAG WILL 將硬體平台賦予最低功率 盡可能使用效能拓撲概念總而言之 裝置進入/維持在這個最低電量等級，或並非由產品決定 行為與政策、環境條件和使用者行為。

設計

系統活動管理者包含以下部分：

  1. 功率元件
  2. 用於初始化、狀態管理和電源處理方式的商業邏輯 級別的變動
  3. FIDL 服務提供暫停/恢復統計資料存取權。
  4. FIDL 服務可讓用戶端保持硬體平台啟用狀態， 暫停/繼續轉場的通知。

FIDL 服務的確切定義將以 API 為例 審查/校正工作階段

電源拓撲

如要瞭解功率拓撲圖慣例，請參閱 RFC-0250：電源拓撲。

電源拓撲 圖表

SAG 會建立並管理電源元素 Execution State， 讓硬體平台執行程式碼這項強大元素 彙整來自其他元件的信號，以判斷暫停轉場的時機 。

透過建立功率元素，SAG 可讓其他元件執行以下操作：

  • 提高硬體平台的執行狀態， 只要版權聲明方仍保有版權聲明
  • 說明硬體平台應繼續執行程式碼的「原因」 透過電源元素及其依附元件鏈結
  • 保留機會式版權聲明，因應執行狀態的變化。 如此一來，SAG 實作就能產生副作用，以回應 每個 Execution State 的功率變化。
  • 最重要的是，RFC-0250：電源拓撲需要一個功率元件 也能展現出最低的功率。因而產生管理 對硬體平台執行狀態的動作 (無依賴電源時) 個元素已啟用。

執行狀態

這項 Power 元素會盡可能與硬體平台的 執行程式碼的能力它支援 3 個功率級別：

  • 活躍
  • 暫停中
  • 已停用

當硬體平台正常執行時，這個元素應該會 電量為 Active 時。裝置電量為 Inactive 時，硬體 平台應處於暫停狀態，或正在積極嘗試 轉換至暫停狀態裝置只有無法感知某些部位 還是應該執行所有省電方式請參閱限制裝置 按執行狀態細分 這種設計模式如要進一步瞭解何時可停用或重新啟用，請參閱暫停/重新啟用 以及暫停的觸發方式

Suspending 功率介於 Inactive 和 Active 功率之間 級別。此電源等級獨立於只有 可在硬體平台運作時執行，以及「可能」 會在硬體平台在暫停狀態與暫停狀態之間轉換時執行 任一方向的執行狀態。請參閱儲存空間範例 。

設計模式

防止停權

如要防止硬體平台暫停，元件可以建構 傳送， 依附元件取決於 Execution State。

假設產品具有媒體播放器功能，他想 以便防止硬體平台暫停 支援連續播放音樂。為了支援這項功能 管理播放狀態可能會在 Execution State 上建立斷言依附元件，以免 SAG 觸發暫停轉換。

透過執行作業狀態防止暫停 圖表

在上圖中，媒體播放器元件有一個稱為 播放。播放功率元素具有 Active 的斷言依附元件 功率 Execution State。需要開始播放媒體時，媒體 播放器元件將要求租用 Active 功率 Playback 以免硬體平台暫停服務租期過後 如此一來，媒體播放器元件就能在沒有的情況下執行媒體播放邏輯 不必擔心硬體平台意外暫停

依執行狀態限制裝置

產品可採用的一種強大圖案，就是限制裝置的權力 並依據硬體平台的執行狀態 加以限制這可以用來 硬體平台暫停狀態的周邊裝置耗電量。阿斯 硬體平台切換成暫停狀態時，驅動程式庫可以關閉裝置電源 或變更其設定如果您要的產品 在硬體平台暫停時關閉特定功能或子系統 以減少耗電量

音訊範例

考慮使用搭載高效能音訊硬體的產品。僅限產品擁有者 想要在硬體平台喚醒時啟用音訊硬體。 產品擁有者可以使用權力拓撲表示這項設定 機會依附元件 Execution State。

依執行狀態限制裝置 圖表

上圖中，名為「音訊」的音訊驅動程式庫具有電源鍵 叫做「電源」的元素音訊驅動程式庫程式對 Active 的功率為 Execution State。音訊驅動程式庫 向 Power Broker 要求租賃，藉此執行依附元件。時間 Execution State 會轉換成 Active，即音訊驅動程式庫在電源上的租期 將要求最佳化屆時，音訊驅動程式庫可以執行任何邏輯 啟動音訊硬體。相反地，當Execution State要求 電源供應器從 Active 掉落後 音訊驅動程式的租期就會變成 不滿意屆時，音訊驅動程式庫可以執行邏輯來停用 音訊硬體設備，再通知 Power Broker 其功率元件已掉落 電量。

處理喚醒中斷

當硬體平台暫停時，外部外部人員可重新啟用 刺激感。這種外部刺激的原因通常是 CPU 中斷 將由其中一個週邊裝置元件引發。能妥善處理起床時間 中斷時，可能發生的情況如下：

  • 系統曾在懸吊前的某個時間點安排駕駛人 Wake 向量的程式。
  • 處理中斷時：
    1. 如果驅動程式庫正在等待通訊埠等候中斷，則表示其中斷處理常式 執行緒 (IHT) 是由核心排定。
    2. IHT 或其他其通知的元件「可能」會建立要封鎖的租約 硬體平台停權。
    3. 驅動程式會與硬體和/或其他元件通訊 處理中斷。在此期間，其他元件 釋出租期。
    4. 中斷處理後，驅動程式會呼叫 zx_interrupt_ack。
，瞭解如何調查及移除這項存取權。

在處理中斷期間，SAG 因為核心而隨時都可以執行 當硬體平台轉換至新伺服器時，可繼續執行已暫停的工作 停權。

儲存空間範例

請參考限制裝置的音訊範例 執行作業狀態 。會時 硬體可能會採用與音訊模式類似的模式，也就是通常關閉此功能 硬體平台暫停時 也會在硬體平台中關閉 平台正在進行切換，暫停中斷或恢復服務。 如果目前已分頁的元件需要電源，這可能會造成問題 並在服務遭到停權前執行清理作業由於 關機作業並不具有確定性，這項簡化的設計是 不足。

解決這個問題的方法之一是讓儲存驅動程式庫在 會發生什麼事

加強儲存空間 圖表

在上圖中，名為「儲存空間」的儲存體驅動程式庫有兩個電源 元素：

  • 電源具有機會依附元件 (執行狀態、暫停)。 當其他電源元素提高 Execution State 的功率時，就能滿足這個依附元件。只要儲存驅動程式庫在以下期限過後仍掛斷電源 執行狀態最多可提升 Suspending，執行狀態無法捨棄 所需的電量。這會讓儲存體驅動程式庫監控何時 應該會關閉電源。
  • 喚醒要求具有斷言依附元件 (執行狀態、 暫停)。這個依附元件會強制 Execution State 提高其功率 第二，自訂角色只能 套用至專案或機構儲存體驅動程式庫收到 Storage 要求。如此儲存硬體才能啟動儲存硬體 即使系統其他部分關閉也沒關係

處理整個系統的轉換

啟動程序

SAG 首次啟動時，會等到系統啟動 才能完成啟動程序處於這個啟動狀態時，Execution State 功率元件應位於 Active 功率內，以反映 事實上，硬體平台確實正在運作，且不會嘗試 停權。

在此期間，其他元件可能會建立依附元件，並釋出 影響 Execution State；但是，Execution State 一律會位於 Active 電量，直到啟動完成為止。為了結束啟動狀態， 針對由 SAG 託管的 FIDL 服務，必須收到啟動完成通知。這個 因此，如果系統的高層可向 運算需求，例如因為使用者互動可能 會經由工作階段劃分

暫停/恢復

系統會在Execution State電量耗盡時要求暫停轉場效果 Inactive 為最低功率，開始進入暫停轉換程序前，SAG 將通知已註冊的事件監聽器，告知即將暫停。為了妥善運用 處理自身、Power Broker 和中斷處理過程之間的潛在競爭 則必須符合下列規定：

  • 如果沒有喚醒中斷，Fchsia Suspend HAL必須傳回錯誤 才能達成這可避免 SAG 在中斷處理常式之前執行競爭 有機會要求租用並確認中斷
  • SAG 不得在暫停時變更 Execution State 的功率 系統仍在處理中。當 SAG 從暫停處恢復運作時， Execution State 應一律為 Inactive。取決於裝置 Execution State 會切換並保持適當的電源等級 切換至暫停狀態的前後和期間SAG 的「鎖定」權力 。Execution State Power Broker 的要求層級變更。
  • 驅動程式或中斷處理常式必須先租賃，才能確認 如果驅動程式庫之後需要執行工作，就會中斷。

當硬體平台繼續執行時，SAG 會收到 Suspender 裝置，指出暫停要求的結果。SAG 將會 然後通知已註冊的事件監聽器，讓他們知道暫停要求的結果。在此之後 等候器可要求租用，導致硬體平台暫停運作。 詳情請參閱防止停權。

也有可能在轉場前暫停要求失敗。 這可能是因為中斷的中斷所造成，它會立即喚醒 硬體平台或其他錯誤如果 暫停要求失敗，SAG 會通知監聽器失敗，並等候接聽者 確認顯示通知如果選擇這項設定，您就能使用產品層級元件 要求釋出並變更系統設定，以防止反覆發生 包括最終失敗的暫停要求

在未監聽器的情況下，如果未監聽器於測試期間提高 Execution State 的功率， 繼續轉換，SAG 會記錄這個失敗情形。發生這種情況的原因 導致聽眾或產品沒有使用中 (或不完整/不完整) 引發的當機問題 產品體驗。

暫停/恢復 圖表

關機

當系統中執行的元件要求關閉或重新啟動時， 元件管理員會開始根據能力圖表終止元件。 如果元件會留住硬體平台，就會造成問題 停權狀態會在 SAG 前終止。這會導致 SAG 在關機期間，意外觸發停權處分。

如要解決這個問題，負責協調關機的元件 (shutdown-shim 和/或 power-manager) 必須保留讓 Execution State 保持在 Suspending 功率等級的租賃。自 shutdown-shim和 power-manager 是最後執行的元件， 重啟，以防止發生錯誤的暫停情形。

實作

如要新增這項功能，必須完成多項變更並提供多項協助 子系統。可細分為 步驟如下：

  1. 基本停權支援
    • Execution State 變為 Inactive 時觸發暫停
    • 繼續時傳送事件監聽器通知。
    • 針對可讓系統保持喚醒的履歷通知連結事件監聽器。
  2. 讓所有重要子系統與 SAG 介面連接電源感知能力。
  3. 最佳化暫停時間。
    • 曝露中斷和/或其他核心喚醒狀況 和/或 Fuchsia 暫停使用 HAL。
    • 使用核心/Fuchsia 暫停 HAL 信號，延後觸發暫停動作 可能發生錯誤的要求
  4. 持續整合其他可感知暫停感知的子系統。

成效

整體系統效能的影響大部分取決於 Power Broker。大多數 SAG 客戶會在 執行初始化來設定依附元件，讓日後互動設為間接互動 由 Power Broker 提供。監聽 SAG 事件的用戶端會有 對系統效能的直接影響，因為他們「必須」確認處理 以及暫停失敗通知我們應該密切監控延遲 指標，以確保繼續執行和暫停失敗 並在產品中及時處理。最後，觸發 Fuchsia 暫停使用 HAL 回報停權狀態。我們應該監控這段延遲時間 確保在各項產品中及時完成停權作業。 這包括監控延遲時間和撤銷暫停狀態對效能的影響 要求。

安全性考量

RFC-0250：Power Topology 建立的電源架構定義了 效能拓撲模式SAG 會透過 通訊協定能力相當卓越存取這項通訊協定有助於其他電源元素 使其依附於 SAG 的功率元件最終，SAG 資安必須依賴 由元件架構為轉送通訊協定提供的保證 能力。

SAG 的通訊協定能力依附於 Fuchsia 暫停 HAL 和 Power 代理人。如果這些元件中的預期行為有任何偏差，可能會導致 SAG 實作中的不良行為。SAG 必須考量遺漏及 不當行為，降低連鎖性負面發生的可能性 效果。

用戶端註冊監聽器可能會遭到濫用。惡意 元件中如未確認事件中的事件， 以便即時處理問題如要避免發生這類問題， 回應逾時。

隱私權注意事項

我們同意 SAG 收集任何個人識別資訊； 不過，系統會收集因暫停/恢復行為衍生的資料，並公開 經由 FIDL 通訊協定提供及檢查這類資料會匯總在 部署在裝置外的系統，由產品負責人和 Fuchsia 工程師進行分析。這個 必須經過隱私權審查才能導入。

測試

SAG 將經過一系列的整合測試和端對端測試測試。 整合測試可確保 SAG 在內部狀態之間轉換，並順利傳送 正確暫停要求。

用戶端可以使用一組測試支援資料庫，測試其實作成果 使用 Power Broker 和 SAG，但移除 Fuchsia 暫停 HAL。這項測試支援 程式庫可讓用戶端叫用 SAG 中的特定狀態，以確保用戶端 都能正確回應變更包括確保 電源轉換效果所觸發的效果會適當處理。A 罩杯 如要安裝仰賴 SAG 電源元件的元件的完整測試套件，則應 包括：

  • 無電力架構
  • 初始的 SAG，以鎖定電源等級啟動狀態
  • Execution State 電量為 Active
  • Execution State 電量為 Suspending
  • Execution State 電量為 Inactive
  • (如適用) 重大作業期間不會暫停

說明文件

因此需要豐富的說明文件來解釋 SAG 在系統中的角色。 設定 (包括產品擁有者的預期)、API 模式及 測試支援資料庫說明文件應包含範例、 操控 SAG 電源元件，並適當使用其 API。 範例應包含設計指南中所列情境的逐步指南 模式一節。

使用本說明文件時，應參考這類說明文件中的 這個架構及其概念

缺點、替代方案和未知

實施此提案的缺點是考量到權力的缺點 整體架構

觸發暫停的信號已去中心化。單一元件無法 除非產品擁有者安排 元件來強制執行此模式這會導致系統行為 不夠明確舉例來說 釋出租期為 Execution State 後，SAG 不得在下列情況中暫停： 其他元件都有釋出元件只會知道已觸發暫停 ，透過註冊 SAG 事件監聽器來增加複雜度。

RFC-0230：Fchsia 中的 Suspend-To-Idle 注意事項如下：

如果使用者空間提供恢復延遲時間的要求，Fchsia 應該 也同樣尊重他人如未提供恢復延遲時間，Fchsia 應該進入 盡可能縮短恢復延遲時間。

這個 RFC 不考慮這項要求，因為只有一個暫停狀態 目前是由平台支援。

我們尚未找出所有可能的電源控制模式 驅動程式和硬體，因此此設計可能需要隨這些原則進行調整 系統就會找出模式包括但不限於恢復延遲時間 以及更多暫停狀態的支援等 需要在後續的 RFC 中編纂。

既有藝術品和參考資料