RFC-0250：電源拓撲

RFC-0250：電源拓撲
狀態	已接受
領域	電源
說明	說明系統電源管理要用於跨相依狀態管理的模型。
問題	337855481
毛皮變化	1004754
作者	claridge@google.com
審查人員	kgong@google.com mbrunson@google.com jmatt@google.com harshanv@google.com andresoportus@google.com
提交日期 (年-月-日)	2024-03-09
審查日期 (年-月-日)	2024-06-03

摘要

系統電源管理的主要問題之一，就是支援轉換作業 泛指不同系統元素中的字詞；這個術語是指帶有 狀態、硬體和軟體等不同狀態，同時妥善管理 這些狀態彼此依附關係本提案指定的是 為解決這個問題而導入 Fuchsia Power Topology 同時提供歸因和歸因方面的相關問題解決方案 可觀察到的情況本研究的重點在於， 定義明確的術語；日後的 RFC 將更緊密地處理設計 和實作相關

提振精神

狀態管理問題

這項提案源自於需要支援系統暫停/恢復 如 RFC 230 中所述。

系統停權的一大任務，就是要確保所有硬體元素 在 CPU 停止執行之前，已放置於適當的低功耗狀態 操作說明。更重要的是，這看起來似乎是 問題一層：已啟用硬體元素的狀態取決於 CPU 主動狀態，因此必須將硬體元素 都處於暫停狀態

然而，硬體元素可能會彼此依附。比方說，裝置必須 在公車無法供電前 暫停使用。同時 系統停權期間可遵守的 像是 是喚醒來源，如果不是，則處於完全關閉狀態。 同時，相關的狀態管理問題並不屬於系統 停權。硬體元素可能會將硬體元素導向低電量狀態，而 CPU 則在運作時 開啟 (例如手機處於飛航模式時) 無線電已關閉。

機構必須考量這些因素，才能打造出可以支援轉換作業的架構 同理，電源管理是主要原因 轉換時不可少，這一切歸功於 Fuchsia 的力量 架構。我們介紹「權力拓撲」也很彈性地指 這兩個架構的核心依附元件圖 機器學習是向機器提供資料和答案 讓機器自行探索規則的科學

我們在開發 Power 拓撲時，發現需要用到 硬體元素之間的狀態依附元件自然延伸至軟體 元素，可在硬體或 以便自然描述面向使用者功能的啟用/停用狀態。於 即可明確擷取 因此，我們會以自然的方式，以隨選即用的方式執行， 使用率，以便只在需要時才使用依附元件，以及 為需要用到的資源提供出處。 要一併歸因給各個元件，但功能細節更完整 圍繞著使用能源的原因，因此必須在非常高的時間內 子元件層級

為了落實以需求為基礎的狀態變更 這些進階拓撲，不僅能編碼 但驅動狀態變更的規則這可以建立 產品開發人員和系統工程師，這些開發人員可以 整個系統的行為，並透過拓撲本身提出功能變更建議 而非原始碼

為什麼要使用新的拓撲？

Fuchsia 使用兩個重要拓撲描述驅動程式 元件。然而，這些都無法隨心所欲地因應 管理問題因此，我們有自己的權利來開發功能拓撲 因為我們會定期重新檢視元件和驅動程式庫 透過圖表清楚瞭解其角色。

為方便參考，我們會簡短說明現有的拓撲。

元件拓撲說明 例如元件執行個體和 能力轉送圖表這是說明元件階層結構的樹狀結構 執行個體和功能會對應至該樹狀結構上方的 DAG。如果 元件需要從其他子樹狀結構存取能力，能力為 並透過父項來轉送

驅動程式管理器也會追蹤本身的節點 做為 DAG 拓撲在驅動程式庫中 節點是裝置的抽象層，驅動程式會繫結至節點 使用相關資源，例如 MMIO 暫存器存取權。驅動因素 這些元件會整併為集合 這種結構的原因是元件拓撲沒有提供 表示沒有驅動程式庫繫結的節點，且節點可以 父項 (這些稱為複合節點) 之間不得有樹狀結構 元件拓撲的結構

相關人員

講師：

Adam Barth abarth@google.com

審查者：

• 電源：Kyle Gong kgong@google.com
• 權力：Michael Brunson mbrunson@google.com
• 驅動程式架構：Justin Mattson jmatt@google.com
• 驅動程式架構：Harsha Priya NV harshanv@google.com
• Zircon Kernel：Nick Maniscalco maniscalco@google.com
• 平台驅動程式：Andres Oportus andresoportus@google.com
• 元件架構：Gary Bressler geb@google.com

諮詢：

• David Gilhooley dgilhooley@google.com
• Corey Tabaka eieio@google.com
• 菲律賓電影 fmil@google.com
• Guocheng Wei guochengwei@google.com
• YoBin Yoon hanbinyoon@google.com
• Eric Holland hollande@google.com
• Mukesh Agrawal quiche@google.com
• 約翰 Wittrock wittrock@google.com

社交功能：

這項設計一開始是透過 Google 內部的設計進行社交化 與權威人士分享的文件 架構、元件架構、驅動程式架構、驅動程式及 Zircon 團隊。這項服務 我們在類似的設計流程中進一步修正了功率 代理程式和系統活動 總督，兩者都是 中所述的 RFC

需求條件

訂單依附元件管理

如先前所述， 系統電源管理是管理不同系統的狀態變更 會遵循這些狀態之間的依附元件。優先放送示例 這類依附元件的影響如下：

• USB 裝置必須先接上電源，才能開啟。
• 電壓軌道完成後，時鐘才能以指定頻率運作 確保供電時的電壓是否夠高
• 影片串流應用程式只有在以下情況下，才能開始串流播放影片： 以及有效的網路連線

一般來說，指定的系統元素 E 可能有狀態集合 S₀、S₁、S₂、...其他都有可能佔用的空間。供 E 至 可正確佔滿指定狀態 S_i，且所有的 同時滿足依附元件

如果作業會保留所有依附元件的依附元件，則我們會順序呼叫該作業 系統元素狀態尤其是對每個含有 候選狀態 S_i：

• E 只會進入 S_i， 滿意
• 如果 S_i 的其中一個依附元件損壞，必須先結束 E 西_i。

電源架構必須支援訂單狀態轉換，才能參與計畫 系統元素

當狀態轉換無法依序執行時，電源 架構應確保元素放置在定義明確的狀態。 讓執行不流暢的元素數量降到最低。

歸因

系統元素可能會佔用多個狀態，其中某些狀態具有更高的能力 。當元素具備較高功率狀態時，Power Framework 必須 找出原因

睡眠效率

系統元素應分配至最低功率狀態 架構可以指出作業原因。架構使用者必須具有 將元素驅動到高功率狀態的簡單方法 可能需要引進新的歸因原因

觀測能力

電源架構必須能夠觀察系統元素的狀態 考量到供電需求

成效

已知有能夠以某種方式執行狀態轉換作業的系統元素 符合一套產品要求 對他們提供支援這會大致分為兩個問題：

• 請勿妨礙本機成效。電源架構不得 個別系統元素的狀態轉換過久。

• 支援非本機效能最佳化功能。Power Framework 應該 支援最佳化跨多個元素的狀態轉換。

  • 舉例來說，假設圖形和音訊子系統繼續進行 系統暫停作業期間同時顯示低功耗狀態。電源 架構應指出它們同時運作並提供深入分析 這會需要較長的時間 因此，系統將暫停最佳化系統的延遲時間 都可以將重點放在其中之一或另一物件上

獨家

效能拓撲促使他們考慮極大的問題空間。這個 提案特別不針對下列主題：

• Power Broker 的詳細規格。此 RFC 必須建立一些 Power Broker 的多個部分來開發拓撲模型。 但是，請盡量保留與 Power Broker 的 配合即將推出的 Power Broker RFC。Power Broker 將 實作在本文件中詳述模型之外的行為，以及 因為我們希望能夠為你提供需要的彈性
• 一流錯誤處理。本文件開發的拓撲模型 沒有明確的方式處理狀態轉換錯誤。這個 排除是前述項目的延伸，也不會影響 關於 Power Broker 的錯誤處理，其主要目的為 限制。
• 惡意行為人。力量與責任分離 代理程式和元素擁有者最終都會 需要考量行為不良且意料之外的元素擁有者 管理基礎架構
• 期限支援狀態轉換。是一種及時強制執行的機制 整個系統的便利性，因此建議您將應用程式時間限制 執行個別狀態轉換

我們會進一步考慮這些問題，因為應用實例包含 Google Cloud 就是最佳選擇

設計

本文介紹的設計會建立電源拓撲的基礎模型。 完全不必經過特定介面或實作實用性 許多即將推出的 RFC 對開發人員而言也很重要 打算將子系統與電源拓撲整合：

• 電力經紀人 RFC 會解決用於管理 電源拓撲和實作這些函式的元件
• 系統活動管理者 RFC 將說明電源拓撲 與系統暫停/繼續程序之間的整合點
• 電源啟用的驅動程式 RFC 會解決驅動程式庫特有的問題 擷取及準備資料、針對特定領域進行預先訓練 調整指示、離線評估和整合

不過，拓撲模型本身就相當複雜 文件。此 RFC 旨在將概念形成連貫的概念 並奠定其他 RFC 可建構的基礎 可製作哪些穩定說明文件來輔助效能 整合架構使用者。

電源拓撲和核心概念

推動這項設計的主要功能是順序和 規定。首先 確立模型可加入模型的系統元素種類、 狀態，以及這些狀態可能傳達哪些依附元件 透過效能拓撲只有這樣我們才能指定狀態的 建立一組新的 Pod

電源元件

電源元素是此設計中的基本有狀態實體。權力 元素隨時都有有限數量的狀態 實際運作的是其中一個狀態建議您考量 做為一般化裝置型號 如同狀態的容器

特定硬體裝置可能直接對應到單一電源元件，但 模型也可以用多個功率元素描述 裝置狀態。舉例來說，您可以個別設定觸控手勢 感應器用於追蹤位置的取樣率和容量；感應器的驅動程式庫 都有專屬的「取樣率」以及「位置追蹤」做為 結果。

電源元素也可用來模擬更抽象的概念，例如 橫跨多部硬體或 面向使用者的軟體功能的啟用/停用狀態。

功率

電源等級是指電源元件可佔用的狀態。A 罩杯 電源水平結構是由一組特定電源等級組成， 電源元件可能會佔用許多空間，我們稍後會說明相關中繼資料。

Power Framework 假設結構定義中的層級遵守數個 限制。架構使用者必須在指定 作為次方元素的結構定義，這些限制可準確反映 模型屬性。這些限制包括：

1. 可以增加耗電量來排序。(您可以透過多種方式 測量功率；目前的意圖和用途 「一般」的定義才能有效消耗電力)剩餘的 限制條件。
2. 依附元件會累積：對於指定元素， 這些在 L 層級正確操作所需的必要項目，任何層級 M > 皆須進行 L.

3. 功能會累積：對於指定元素，任何提供的功能 層級 L 也會由任何等級 M > 提供L.

   • 這項規定可避免合作夥伴 一個冪等元素的相依關係舉例來說，如果一個相依關係 第二層的功能需要 (N+1) 時，元素只要以 (N+1) 位置進行，即可同時滿足兩者。

電源層級架構則由以下元素組成：

• 結構定義中每個功率等級的標籤。
• 增加耗電量所得等級的順序。

範例

為方便說明，我們將使用字串標籤並代表排列順序 並以由下到上的順序排列垂直清單(詳細步驟說明 實體都會出現在 Power Broker RFC 中)。

三種可能的功率配置如下圖所示：

二進位檔開啟/停用配置 已開啟 關閉

低耗電模式的三元配置 完全開啟 低功耗 關閉

不含 D0ix 的 ACPI D-States D0 D1 D2 D3hot D3cold

值得注意的是，電源等級是按照 ACPI 電源狀態。透過這項選擇，有助於釐清 輕鬆用詞。依照 ACPI 慣例，使用「低耗電狀態」這類運算式 兩個直接不一致的解釋為 套用至耗電量 (對應此批次中較高的指數) ) 或按排序順序排列的索引 (對應於較高的次方) 消費)。「低功耗等級」等運算式遠離這件事 模稜兩可。

部分功率元件無法使用 會與其他元素共用例如，某個屬性可能會定義 會指定 CPU 的運作頻率下限；如果採用每秒影格數，則 等級會對應到相關 CPU 的支援頻率

用途和限制

電源層級結構定義是表示元素狀態的實用起點 基於各種原因：

• 這張圖很清楚地表現出共同的模式， 上述。
• 可讓您擷取 將大量狀態提供給使用者 冗長的重複字詞。
• 使用方式不得發生衝突，也就是無法 但應盡可能使用。

單一電源元件和電源等級結構定義不足以描述所有 鎖定 Power Framework 使用者的興趣。例如脫水、部署 單一裝置的模式 (做為一個簡單但不經過說明的例子， 系統無法將某些房間的熱泵視為單一項目 冪等元素

不過，電源等級結構定義可以做為構成要素，用來補充說明 複雜的系統最佳做法不在此 RFC 規範範圍內 請參閱後續的說明文件。 架構使用者也可以透過 紫紅色 >電源 元件。

運作性與依附元件

根據目前系統情況，在任何指定時間點使用電源元件 就足以讓系統正常運作。這些 其作業能力層級。這個子集一律包含小於 或 的所有層級 等於最大作業層級，以元素 E 表示的 max_operable_level(E)。

「電源等級依附元件」是一種表示運算能力的條件 其中一個功率元件的目前功率相關 元素。電源等級依附元件表示子項元素 C 可 會在 L 級或以上級別操作，則需要父項元素 P 才能在 所需的等級 RL更確切地說，將 (C、L) 依附於 (P、RL) 表示：

• 如果 current_level(P) <RL，然後 max_operable_level(C) <L.

同樣，這個條件可以表示為：

• 只有在目前_level(P) ≥ RL 的情況下，max_operable_level(C) ≥ L 才會改善。

每個 (C、L) 的依附元件都會建立 L 所需的條件 作業。依附元件可稱為「符合」、「已履行」等， 相關條件的狀態

此外，請注意任何等級 K <L，每個 (C、K) 的依附元件都會建立 L.尤其是 (C, L) 即使 (C, L) 本身也可以對父項元素加上必要參數 不會直接依附於該元素所有 元素都稱為 這類需求條件 (C, L) 的必要元素。針對此 設定後，(C, L) 必須設有最低需求等級；我們代表 此 min_required_level(P; C, L)。

匯總所有必要元素，下列必要元素集合 必須符合條件，L 才能運作：

• 所有 P ∈ 的 current_level(P) ≥ min_required_level(P; C, L) required_elements(C, L)。

滿足這些條件時，我們會說 L 表示「異常作業」。敗場 可能無法正常運作；當地情況，例如 (可能未觀察到) 硬體錯誤，可能會導致 C 無法在 L 的情況下運作 以及所有相關的電源等級依附元件名詞 運算能力應視為強大拓撲嘗試建立模型的方式 真正的可操作性雖然這兩種概念彼此不一致是不可避免的 只要元素設計人員 以做出選擇

一個功率元件可能對另一個元素具有多個功率性依附性。 針對固定父項和子項的所有此類層級依附元件集合，構成一個 電源元素依附元件。我們會說 C 依賴 P 從至少一個 C 層級到 P 的其中一個層級。

功率拓撲

做為正式實體，功率拓撲是具有力量的多邊圖形。 作為節點，並以向邊緣取代電源等級依附性。三 此外，這個圖還設有下列限制：

1. 非循環性：權力拓撲屬於循環化。

   • 具體來說，父項/子項關係的運作方式會與預期相符：如果 C 元素依附元素 P，因此 P 可能不會依附 C。

2. 最低可操作性：最低層級 無論 當前與其他元素的不同程度此外，裝置也可能沒有電量 依附元件

   • 此條件指的是可操作性，而非名詞操作能力 而且能確保每個元素都至少有一個可操作等級。 必須由元素擁有者強制執行。

   • 允許一個元素的最低等級依附於另一個元素的 不會影響操作能力但這種依附元件 就是功能不相關的功能 考慮「僅」透過本身的 最低層級

電源拓撲可能包含備援電源等級依附元件。例如： (C、L) 可能取決於 (P、RL₁) 和 (P、RL₂)，其中 RL₁ <RL₂ 對 (P、RL₂) 的依附元件比 依附元件 (P、RL₁)。這類冗餘情況視為無害 可能需要特別考量 。

範例和背景資訊

注意：這些例子僅供參考，這個 RFC 沒有任何影響 介紹哪些模型需要使用電源元素建立模型

電源層級依附元件最基本的形式與開啟/關閉狀態有關。非常 簡化範例，我們可能會表示必須開啟 USB 匯流排， USB 裝置連線：

必須開啟公車，才能依序處理上述依附元件 而且裝置必須在開機前關機， 公車已關閉。

電源等級依附元件的定義越廣泛，就越能因應更複雜的情況 ，例如在 DVFS 期間結合時鐘與電壓。 (DVFS 具有足夠的時效性，因此不太可能是理想的人選) ，但可做為實用範例)。假設我們 具有時鐘的時鐘和下列 DVFS 表格，列出支援的頻率，以及 所需的電壓：

時鐘頻率	電壓
1.6 GHz	900 mV
1.5 GHz	800 mV
1.4 GHz	700 mV

下表為電源元素、等級和依附元件轉譯文字，如下所示：

(請注意，當裝置 (電壓、700 mV) 依賴 (時鐘頻率，1.4 GHz) 時 「不會」納入拓撲中，但 以便和表格進行比較)。

代表軟體功能或使用者層級等項目的強大元素 裝置的操作模式可能會具有許多依附元件，用於描述所有 正確運作所需的資源另一個簡單的例子是影片 呼叫客戶的「有效」級別可能取決於各種硬體子系統 撥打電話時需要：

最後，多個子元素可能會依附同一個元素。這裡描述的是 裝置會偵測裝置的延遲時間客戶 A 已啟用 級別需要低延遲，而用戶端 B 則需要中等延遲時間。裝置 採用低延遲作業，可以滿足兩個孩子的活動程度。

本範例說明電源等級的重要屬性：它們是 並且定義不同用戶端的需求不得發生衝突。

邊緣方向慣例

如目前為止的圖表所示，我們採用 1000， 拓撲採用從子項到父項的依附元件方向。大概 無法避免某些討論和直覺式術語是以 也就是從家長到子項的電源流方向目前我們的用意是 將所有依附元件的方向運用在正式開發作業上 並建議讀者註意這個問題。

管理權力

為了指定如何在實際系統中運用電源拓撲，下一步 您需要定義管理拓撲和個人的 進階元素

電力經紀人

電源拓撲將由 Power Framework 元件管理 名為Power Broker。Power Broker 會在 包括所有電源元件、其功率架構， 電源等級依附元件和當前電源等級Cloud Run 會提供介面 讓元素擁有者自行更新元素和電量需求 在這些時間內，盡量按順序變更等級。

Power Broker 的存在反映出這項設計的關鍵斷言：權力 拓撲將會集中管理我們認為這是必要措施，原因如下：

• 若嘗試在本機管理拓撲，可能會產生相當大的 依附元件管理中導致實作錯誤的機率變多。
• 中央管理員擁有連線所需要的系統全系統權限 提升功率以因應電力使用需求 成本效益的要求。
• 中央系統管理員有權在服務中執行歸因 註明出處規定。
• 中央系統管理員可以維護詳細遙測資料，並回報給 符合觀測能力規定 表示個別子系統未提供檢測作業。
• 由中央行政管理人員有機會清楚地將代理商移除 不該有這個元素的所有元素擁有者舉例來說 優先考量，駕駛人不要就電流下決定。 降低基礎硬體等級可明確指定 並導致租用 自己的進階元素

集中化管理作業需要負擔本地化成效 成本，因為管理員實施的那一方必須注意電源 及其層級因此，效能必須謹慎 和執行 Power Broker 的設計和實作。不過，全球 Power Broker 可支援的另一個角度是希望 且有機會最佳化整個系統的效能。

元素擁有者

每個功率元素都與單一元素擁有者相關聯，即 (可能是 DFv2 驅動程式庫) 負責管理元件 擁有者向 Power Broker 註冊元素，宣告其功率層級 定義其依附元件，並視情況更新電源等級 次。

如有需要，元素擁有權可以在 元素的生命週期這很可能會涉及單一元件執行個體 做為註冊和設定工作的擁有者 並獲得執行階段管理的擁有權

電源元件的生命週期及相關依附元件的生命週期將 已在 Power Broker RFC 中所述。

功率元件類型

大多數的進階元素將受到「管理」，也就是擁有者延後 選擇電量及 Power Broker 變更的時間。通知 需要變更元素層級時，Power Broker 會通知擁有者 規定等級。擁有者做出變更，然後通知 Power Broker 元素的新目前層級。

在目前的模型中，我們簡化了假設，收到通知時 E 必要的 RL 元素，E 的擁有者一律會：

• 如果 RL 可操作，請將 current_level(E) 更新為 RL。
• 如果 RL 無法運作 (例如嘗試在嘗試執行時發現硬體錯誤) 更新 E 目前的等級)，請採取行動讓 E、RL 不再適用 表現優異。(例如，錯誤狀態 元素，可用於指定 (E、RL)。

因為我們不能徹底處理可能的錯誤狀況。相反地 它會委派 Google Power Broker 的錯誤處理開發工作 (如同 排除)，同時指向主動式錯誤處理的方式 可以找出任何可能的項目

未受管理的元素稱為「非代管元素」。不可包含 而其擁有者只是將目前的等級回報給 Power Broker (只要圖層的等級變更)。其目前的等級會影響 相關的元素

這類元素必須說明非軟體狀態 這類元件只能進行觀測，例如硬體切換 或是硬體的錯誤狀態

電源控制

透過受管理的元素，Power Broker 將負責推動大部分的電力 在整個拓撲中保持一致為了限制 我們在 RFC 1919 提出的問題 行為。

Power Broker 的控製配置是為了在需求之間取得平衡 。

從概念上來說，裝置功能消耗電力的需求 Google Cloud 就是最佳選擇這些需求通常會根據特定的 瞭解使用者對裝置的期望。使用者開啟 應用程式執行特定工作，表示特定電源元素 所需的電量資訊 與此應用程式相關聯 或者，裝置可能會偵測出使用者就在附近 可能很快就會互動，建議裝置進入模式時 因此可以低延遲的回應廣告需求甚至取決於應用程式能否滿足需求 處理器未處於閒置狀態，以致於使用者未預期互動 喚醒裝置，例如說出啟動字詞、點選滑鼠、輕觸螢幕 等。為了表達對電源拓撲的需求，我們將推出 稱為釋出的物件。

同時，相關限制可能有兩種不同情況。在單一案例中 未受軟體控制的使用者可直接禁止電源使用；這是 由非代管元素建模。另一方面 系統可能需要某種方式來指出電量應該或不應 以滿足租期提出的需求滿足這項需求 依附元件執行要求政策。

這些概念讓我們能夠指定穩定狀態 電力經紀人會引導系統，同時考量時間細節 是 Power Broker RFC 的

穩定狀態

在任何時間點，都有一組因素會決定受管理元素的「穩定狀態」。 即 Power Broker 所引導的功率層級，只要 保持不變在 RFC 範圍內 仲介商在穩定狀態下的控製配置。這麼做讓我們能夠 介紹相關重要概念，同時限制細節數量 這通常代表交易 不會十分要求關聯語意

狀態穩定

穩定狀態的決定因素如下：

1. 拓撲結構，即電源元素和依附元件。

2. 租賃。

   • 釋出是代管項目的授予項目 元素，針對指定電源等級的所有依附元件 符合條件。根據元素層級 (C、L) 的租約， (C、L) 本身，以及 (C、L) 所需的各個元素層級。

     租賃表示特定元素層級有需求 源自於功率拓撲以外的來源。租賃建立 電源使用原因，詳情請參閱 規定。

3. 非受管元素目前的層級。

只要這些決定因素有任何變動，都會重新評估穩定度 時間。

評估穩定狀態

因此，判斷租期將 為 fulfill，則代表租用元素層級的所有依附元件都會 滿意

Power Broker 將以不雅方式處理租約。如果有 釋出 (C、L)，但 Power Broker 無法或無法滿足 (C、L)，除非執行 因此能達成不同的租約

為了判斷是否要完成租賃，Power Broker 必須同時決定是否提供租賃 可以執行租約，以及是否應執行。關於「可能」的問題是 功能需求，且會由非受管元素的層級處理。 回答「應該」需要新的概念 不是 Power Broker 可主動滿足受管理的依附元件 元素。

為此，我們制定了兩種可能的執行要求政策。 等級依附元件：優異的執行要求和執行方式弱。A 罩杯 只有在依附元件元素受到代管時，系統才能顯著地提供依附元件。 代管和非受管元素的依附元件 也可能像這樣 強度不足

執行要求政策也會匯總至依附元件的路徑。路徑 如果路徑中的每個依附元件位於 高度供應；否則就較缺乏彈性

考量到一組固定的狀態決定因素，我們能夠指定 何時才能租用租賃 (C, L) 處於平穩狀態 狀態只有在每個元素層級 (P、RL) 依附於 較弱的路徑

• 如果 P 未管理，則 current_level(P) ≥ RL。
• 如果由 P 管理，則其他已執行的租約就需要 (P、RL) 才能運作 並仰賴具有強大功能的路徑

一旦確認釋出租期，便能維持穩定狀態 任何受管理元素 C 的層級都只是 已完成租約，或如果未符合租期，則需要 C 的 C 單位 級別。

訂單項

Power Broker 可藉由執行 作業。較特別 請注意，如果所有穩定狀態的電量皆大於或等於目前電量 才足以保證朝穩定狀態前進 順序。

在某些情況下，電源等級可能會發生異常變化 減少針對這類情況，我們推出兩項終止政策。 針對電源等級依附元件：訂單終止和 因順序不符而終止。代管元素的依附元件一律為 終止順序，未受管元素的任何依附元件 順序錯誤。

如同執行要求政策，終止政策一樣匯總至 依附元件如果路徑中的所有依附元件都是順序在終止，那麼 是順序不斷的否則，此為全行不停的。

如果 (E, L) 透過順序至終止路徑 (M、RL) 影響，則「電源」 代理程式會盡可能降低 current_level(E) 造成的影響 低於 RL 之前 L 的值。相反地，如果 (E、L) 仰賴 (U、RL) 透過無效路徑終止，本文件 此模型不保證階段層級變更的順序 route_level(U) 應減少在 RL 以下。

就非受管元素的部分情況更具體地說明情況 並考慮使用 (U、RL) 於 (U、RL) 的失序依賴性依賴性 就是未受管理的項目如果 current_level(U) 低於 RL，則這個事件 不受 Power Broker 控制。沒有機會提升 Current_level(E) 比 L 早之前的 L；電源代理程式必須降低 做出明智的決策由於傳輸依附元件 (U、RL) 也已損毀 一旦 U 目前的等級下降，將沒有明確的等級變更順序 提示系統進入穩定狀態

依附元件類型

上方的正式說明分別介紹三種依附元件。 命名方式如下：

依附關係類型	出貨政策	終止政策
基本資料	弱	失序
隨機	弱	井然有序
宣告	強	井然有序

基本依附元件一律是非代管元素中的代管元素。 而斷言或機會式依附元件一律是單一管理的 另一個受管理的元素

範例

非受管理的元素

這個範例說明在含有 硬體靜音開關元素如下：

• 靜音開關：關閉靜音開關時，系統的麥克風 正常運作。互動時，麥克風會固定時鐘， 卻沒有什麼限制

• 輸入串流：代表從 音訊子系統提供給應用程式的麥克風。產品使用中 此等級具有基本依賴 (靜音開關、已中斷) 的依賴。

• 音訊處理器：這個元素屬於處理 為不指定目的傳入麥克風資料

• 系統活動：此元素會抽象代表任務的廣度 系統支援的處理工作當這個元素為「高」時，系統會 處理各種任務當狀態不足時 以更選擇性的方式處理任務

步驟：

一開始，「音訊處理器」和「啟用中」的租約，包含所有受管理元素 和電量充足

靜音開關已開啟，並且立即設為靜音開關的電源 已改為不再互動兩者的依附元件 (輸入串流、啟用) 和 音訊處理器 (已啟用) 現已故障。

Power Broker 立即將輸入串流和音訊處理器提升到 電源處於閒置狀態。由於兩個元素 使用中的電源等級已有不滿意依附元件。

當音訊處理器的依附元件不再處於啟用狀態時，系統活動 已轉換為停用狀態。

代管元素的機會依附元件

在此範例中，系統活動元素必須設為「高」才能使用兩項功能 容器才能載入應用程式高優先順序功能的依附元件是宣告的，所以系統 根據租用權限 (高優先順序功能、 已啟用)。但低優先順序功能的依附元件 在高優先順序功能的租期上將系統活動升為啟用一次時，將系統活動提高為 高。

步驟：

目前已有租期 (低優先順序功能，啟用)，但 Power Broker 不會 因為依附元件 (系統活動，高) 是機會式，因此可以滿足這項需求。

已採用租約 (高優先順序功能，啟用)。這會變更穩定狀態。

「系統活動」會提升至「高」。

在無特定順序的情況下，這兩個特徵等級都會提升至「啟用」，同時滿足兩者 租用。

「保留」狀態 (高優先順序功能，已啟用) 遭到捨棄。全新穩定版本 將不再開放租用 (低優先順序功能、啟用)。

高優先順序功能已降低為停用狀態。(注意：此 RFC 不保證 ，這個狀態變更會發生在低優先順序功能等級降低之前)。

為了維持順序，「系統活動」會保持「高」，直到低優先順序功能變更為「高」為止 已調降為非使用中狀態。 這個步驟會突顯許多人對於機會依賴的特性 感到驚訝機會依附元件與斷言依附元件不同 執行方式不同，但 Power Broker 會將這兩種依附元件類型一視同仁 有助於確保電源關閉序列的順序。

「系統活動」最終會降為「低」。

錯誤狀態元素

元素擁有者可以使用非受管元素來建立錯誤狀態的模型 阻礙特定功率的操作能力。下圖說明 L₀ 層級的元素 E 可能兩個可能的錯誤元素， L₁、L₂、L₃。

在最上層的情況下，錯誤元素的層級會直接與 E 的鏡像相同。如果 current_level(Error State)=="L_i OK"，然後 L_i 是 E 可以在多少範圍內運作在底部情境中 錯誤元素會在 L₂ 或 L₃ 發生以下情況時禁止 E 作業： current_level(錯誤狀態)==錯誤。

這項機制只能停用頂端的連續層級區塊 指定元素的結構定義你可以透過其他機制停用等級 至少一個等級仍可運作，但我們希望能 檢查未來的用途。

歸因

Power Broker 支援將目前電源等級歸因於租賃 能滿足什麼條件但若確實有效，Power Broker 將提供支援 彼此間斷地要求特定程度的租賃 隨機挑選一個 API 執行個體

觀測能力

Power Broker 會公開電源元件的相關資訊，包括其功率 透過 Fuchsia 著名的診斷工具，找出層級結構定義及其依附元件 相關成本。更是能進一步記錄租約和電量 轉換在合適的適當、可能可設定的回溯期上。 整體而言，這些資訊將有助於檢查拓撲的狀態 同時也能啟用未來工具 所有拓撲最近的歷史紀錄

設定

電源拓撲許多層面都可透過靜態方式直接擷取 此外還會從 0 自動調整資源配置 您完全不必調整資源調度設定例如前述的 USB 範例 透過圖表描述如下：

    [
        {
            name: "USB Bus",
            levels: ["Off", "On"],
        },
        {
            name: "USB Device",
            levels: ["Off", "On"],
            dependencies: {
                "On": ("USB Bus", "On")
            },
        }
    ]

必須從元件中識別元素時，就會增加複雜度 界定範圍讓靜態設定直接設定的技術 與元件架構團隊共同參與調查。

未來主題

轉場延遲支援

長期來看，效能拓撲旨在提供 瞭解並最佳化系統狀態轉換的延遲時間。電源 元素定義會建立一組標準位置，用來對預期進行編碼 以便設定局部轉換延遲時間，例如變更元素 並滿足所有依附元件局部元素的延遲時間不會 但可在日後成熟時加入。

本機延遲時間的應用包括：

• 半靜態分析 (例如：擷取位於 執行階段) 的延遲時間。
• 執行階段追蹤觀察到的延遲時間，並回報從 到 發車時間 期望。
• 產生用戶端預估的延遲時間，以支援其運作 以及時間要求

其他類型的狀態和依附元件

電源層級和我們導入的依附元件類型都很有參考價值 基於各種原因代表元素狀態的起點。他們 可讓您擷取 透過這種方式彙整資料，而不需要繁瑣的重複步驟。他們 彼此之間不會產生衝突 。

隨著 Power 拓撲不斷演進，它可能會很實用且/或支援 其他類型的狀態和依附元件例如：

• 感應器的韌體可能會用於支援一組不連貫的 每種模式都經過最佳化 但並未遵循嚴格增加的規模 應用程式的運作效能和電力使用情形也許我們能夠 的二元權元素，我們可能會改為導入新的 可以同時描述所有模式的狀態結構定義， 解決競爭客戶之間的衝突。
• 某些類型的硬體 (例如 GPU) 可能會根據硬體選擇的功率 以便靈活因應多個用戶端同步載入需求。有可能 ，以支援 Power 拓撲，支援擷取此類負載的依附元件 以一般方式累積要求

目前這類發展屬於推測性質；就必須重新造訪 與電源拓撲整合。

實作

Fuchsia 導入能量拓撲本身並運用於 是一項大工程如果有幾項程序要進行 因此需要大幅修改 。同時，Fchsia 子系統對 的電源管理機制 適當的電源管理策略，並搭配對應策略 啟用效能拓撲

最好分別思考各階段的開發策略 都是歷史資料第 1 階段的核心功能是 並在第 2 階段進行少量整合以示範 金鑰用途，並啟用端對端測試系統暫停/繼續測試。配備 考量到前兩個階段，我們現在會在第 3 階段奠定基礎 以便整合更多產品，並形成穩定的開發週期 第 4 階段後所述。

第 1 階段 (歷史)：核心功能

• Power Broker 可管理電源拓撲。
• 「系統活動管理者」會定義及管理支援哪些元素 系統暫停/繼續作業。
• 驅動程式架構支援整合驅動程式與 Power Framework。 (電源架構功能將透過 標準機制，不需要特殊支援)。

階段 2 (歷史)：概念驗證電源架構 整合功能

• 與驅動程式庫進行初始整合，將硬體放在 才能達到事半功倍之效
• 與支援 Wake 來源的驅動程式庫進行初始整合。
• 在端對端暫停/繼續工作流程中首次使用。

第 3 階段 (撰寫時間)：向上擴充

• 影響此 RFC；提出及批判 RFC 以獲取權力 代理程式、系統活動管理者和電源感知驅動程式。
• 說明現有實作項目造成的設計限制特性，例如 有效頻率限制是因延遲時間增加而造成的。
• 透過 Power Framework 整合並設計下一組子系統，以瞭解其範圍並設計。
• 制定及記錄最佳做法和設計模式。
• 找出並實施小規模改善措施來協助整合 (例如改善 API、直接進行最佳化)。
• 制定測試程序，並支援整合 Power Framework 的特定領域問題。

• 識別對大規模新增特徵的優先順序最高 可能的應用方式包括：

  • 支援追蹤轉換延遲時間。
  • 需要大幅變更介面的效能提升幅度 和/或後端實作
  • 簡化元件架構整合。

第 4 階段以上：進一步整合及大規模改善

• 整合進一步的子系統。
• 視情況最佳化現有的整合作業。
• 持續根據新興需求進行小規模改善。
• 解決優先程度最高的重大改進項目。
• 找出大規模改善措施 (如果有的話)，以在下一個階段中解決。

成效

關於成效的許多層面，最適合在階段 與 Power Broker 高度相關的 3 個 RFC 建立提案的概念但在目前的範圍內 一般指南。

本地成效與非本機成效

本地和非本地廣告活動的成效 這些需求搭配使用 Power Broker 通常不會產生一些開銷，只可以減少開銷。 完全經過本地化的解決方案。不過，僅採用本地化的解決方案無法有效 支援執行非本機有效運作所需的系統層級分析 最佳化

找出延遲負擔

電源代理程式管理電源拓撲將產生一定金額 尤其是由於元素擁有者和值區之間的 IPC 代理程式。但請務必審慎考量各項成本 真正的負擔特別值得注意的是，有些子系統本身需要 執行程序之間進行通訊，以執行任何形式的電源管理， 和電源拓撲的整合可能實現 間接透過 Power Broker 直接提供。

以大小為準的延遲負擔

因全系統暫停和繼續執行等作業而造成的延遲負擔 但大多會受到子圖表大小影響 並瀏覽相關內容請務必瞭解子圖表帶來的影響 包括深度、深度和節點計數。

QPS 驅動的延遲時間負擔

Power Broker 的 QPS 主要驅動程式庫目前預計： 暫停禁止租約；有關相關技能元素的詳細說明，請參閱 系統活動管理 RFC。

至於 Power Broker 必須支援的 QPS，則尚未達到明確的規定。 某些子系統整合項目可能會需要 因事件獲得的事件頻率夠高，因而暫停訂閱 釋出租約會產生太多負荷。在這種情況下，替代設計模式 發展，將多個事件的處理程序整合至在單一 Pod 中 單一暫停限制租約

為協助進行這類評估，預估每租借延遲時間將為 非常重要

安全性考量

安全性應仔細考量 第 3 階段 RFC 因為較接近具體導入的提案，能提供更明確的範圍 則討論。以下將概述因使用 電源拓撲

電源依附性和功能

因為功率拓撲會使用依附元件，將電源元件提高至較高等級 能宣告特定電源元件的依附元件 本身就是特殊權限作業因此，為了遵循 Fuchsia 的安全 依附元件宣告應該明確受到能力保護 至少為每項元素至少設定一個精細的等級

到目前為止，Power Broker 已採用集中式版權管理方法， 根據目前支援的能力類型，嚴格處理權限。 這種做法經得起考驗，希望能更快實現 瞭解電源拓撲的影響 元件架構長期來看，「元件架構」 表示與功率拓撲相關的功能 自然而然緩解部分安全性相關責任的 Power Broker 並協助開發人員享有更流暢的體驗

集中行政風險

使用 Power Broker 做為中央管理員，此舉暴露在風險上，例如 DDoS 攻擊：可能無法管理重要系統狀態 轉場、規避其權限邏輯的行為，可能導致 攻擊者惡意運用硬體狀態

隱私權注意事項

由於詳細子系統狀態會在裝置上追蹤，因此 決定如何在機群中運用這類資料時，尊重隱私權疑慮 指標。最快在第 4 階段或之後發生 我們才能具體說明 Power Broker 可能會匯出 需要大量的子系統

測試

第 1 階段已針對所有功能進行單元測試 以及針對 Power Broker 的假用戶端進行整合測試 整合測試將 Power Broker 與系統活動管理長相輔相成。

第 2 階段新增了端對端暫停/繼續測試和支援服務 針對系統活動管理階層執行非密封的驅動程式庫測試。

第 3 階段：透過程式庫和 文件，說明如何在各種用途中測試 Power Framework 的整合作業 而且也擴大了 進行測試。

說明文件

這個 RFC 可做為核心概念定義的可靠資料來源 拓撲

說明文件會逐一新增至地址，但僅列舉部分內容：

• 針對本文定義的概念，提供可讀性最佳化的說明。
• 整合指南
• 實際電源拓撲整合範例。
• 電源元素的建議使用模式。

缺點、替代方案和未知

缺點

與這個提案相關的兩項主要費用如下：

• Power Broker 之實作。撰寫本文時 實際執行實作，且在概念上僅有些微偏差 所以費用很小
• 區分用戶端整合的費用。我們將調查 我們會透過說明文件、用戶端程式庫 (留意 FIDL) 評分量表的注意事項) 和測試支援。

替代方案

分散式電源控制

做為電源拓撲的極端替代方案 使用者可能會認為是系統 而不是集中式電源管理程序在這些系統中，子系統會提供 也可能用於驅動不同電源狀態的自訂介面。

適用於任何需要子系統在特定電源才能運作的系統全系統模式 狀態，一些「模式控制器」就必須負責確保 確保每個子系統都處於適當的電源狀態。沒錯 實體就需要使用每個子系統專用的介面

負責有效控制指定模式電源狀態的實體 就會「在該模式」執行集中式電源管理，因此此方法 也就是真正去中心化同時，需要模式控制器才能控制 子系統透過自身選擇的介面，建立明顯的 問題。這些因素共同體現了 Fuchsia 的期望。 支援至少一種集中式電源管理機制 介面標準化

值得注意的是，本提案在 子系統應使用電源拓撲部分子系統開發人員可能會發現 僅公開一或兩個 整體子系統狀態到必要的電源拓撲，以便整合 系統模式轉場效果會比較好有些則認為，請花一點時間深入瞭解 整合整個平台中的子系統模型 驅動程式。

作業順序

除了狀態式與依附性方法，我們也建議使用 將特定運算的序列標準化，基本上為 駕駛人「暫停回呼」的概念以及「繼續回呼」為 來建立作業系統在 Linux 中 暫停/繼續， 可能暫停 (prepare、suspend、suspend_late、 suspend_noirq) 和四個履歷表 (resume_noirq、resume_early、resume、 complete)。

我們選擇不使用這個方法的原因有很多：

• 系統可能會隱藏裝置處於系統停權狀態的狀態 或是處於恢復狀態公開這類狀態的過程 大致上應建立這裡提出的拓撲此外，這類狀態 是否取決於裝置在運作時的行為 已暫停。

• 令觀眾感到困惑，無法得知自己是否「停權」和「resume」描述 使用者在特定裝置或系統上 執行的操作。

• 如 _late/_early 和 _noirq 回呼變化版本。

• 訂單依附元件管理的問題適用於 並且不只是整個系統的暫停和恢復作業。

• 摘要中仍然有跨狀態依附元件圖表 會採取作業序列方法，不過在原始碼中是隱含的。

命令式電源關閉

除了以量計價之外，Power Framework 也可以改用 命令式電源關閉模型，其中電源元件預設為高功率 並明確指示降低狀態。這種做法 特定功能在短期內導入 未追蹤依附元件的導入安全漏洞。另外， 歸因機制就無法自然支援歸因。

同時，以量計價模式可以因應命令式關機設定的要求 某些範圍內的資源具體而言，電源拓撲的具體來說 需要將資源提取至所需用途的取用端元素 預設電量，同時取用者提供變更使用者介面 視需要調整等級接著，取用端元素就能明確地 代表在系統層級檢視畫面中使用命令式電源關閉的情形。

延遲的主題

我們將在 Power Broker RFC 中解決下列問題和問題：

• 元素和依附元件的生命週期長度。
• 租用生命週期。
• 根據指引，與電源等級定義的 API 版本管理問題 相容性提案中，待處理 更新時間是來自 2024 年 4 月 22 日的討論。
• Power Broker 是否會對待租賃的持有人提供任何意見？
• 與拓撲整合的子系統指南 特別是使用假的 Power Broker 與真實 Power Broker 之使用時 與假的能量元素搭配使用。
• 提供不可部分完成新增/移除依附元件的 API。
• 處理冗餘依附元件。
• Power Broker 異常終止時的行為。
• 元素擁有者當機時的行為，包括與優雅的比較 關機/開機。
• 處理錯誤。

既有藝術品和參考資料

Linux

• 裝置電源管理基本概念
• Linux 中暫停使用支援模式的演變 核心
• sysfs 電源介面
• 裝置連結

Mac 作業系統

• 管理權力 - IOKit 基礎知識

Windows

• 電源管理總覽 架構
• 裝置電力狀態
• 電源架構 (PoFx) 驅動程式 範例