RFC-0209：記憶體優先順序設定檔

RFC-0209：記憶體優先順序設定檔
狀態已接受
領域
  • 核心
說明

使用設定檔將 VMAR 標示為優先。
問題
  • 101641
毛皮變化
作者
審查人員
提交日期 (年-月-日)2022-08-16
審查日期 (年-月-日)2023-02-15

編輯此 RFC

編輯 RFC 中繼資料

摘要

請使用設定檔物件指示 盡可能減少頁面錯誤和其他可能導致 允許設定檔套用至 VMAR，藉此降低記憶體存取延遲時間。

提振精神

Zircon 是過度修訂版本系統，並採用不同的回收系統 嘗試支援這些應用程式這些回收方法包括 例如撤銷、頁面表格重編、零掃描等等 處理期限工作，因為這類工作可能會使記憶體的延遲時間增加 存取。日後可能採用的重編方法 (例如網頁壓縮) 會 也會發生問題

音訊是一再出現的例子，核心的任何重組 會導致音訊執行緒中的後續頁面錯誤，進而造成音訊執行緒 錯過期限

到目前為止的解決方案是核心中的特殊案例解決方法 停用所有類型的重述功能，但只適用於音訊相關元件。不過 這種做法非常脆弱，也無法擴充 Google Cloud 就是最佳選擇

這個 RFC 旨在提供同時適用於音訊和替換系統的一般機制 和任何其他元件。

相關人員

講師：

jamesr@google.com

審查者：

eieio@google.com、rashaeqbal@google.com、tombergan@google.com

諮詢：

andresoportus@google.com

社交功能：

與 Zircon 團隊和 也就是 Kernel Evolution Working Group (KEWG)。

API 設計

如要讓使用者擁有重組權限，設定檔物件將會 擴充方式有兩種：

  1. 以下程式碼的額外標記 ZX_PROFILE_INFO_FLAG_MEMORY_PRIORITY： 將會新增 zx_profile_create 和 memory_priority 欄位。
  2. 透過「zx_object_set_profile」可將設定檔套用至 擔任 VMAR。

一開始，系統只會支援 memory_priority 欄位的兩個值： ZX_PRIORITY_DEFAULT和ZX_PRIORITY_HIGH，高度禁止全部停用 。會議室日後可以支援其他等級 ，在最短延遲時間與防止 OOM 之間做出取捨。

將設定檔套用至 VMAR 時 (假設該設定檔具備 memory_priority，該 VM 會立即套用至該 VMAR 及其所有 子區域進行更改。

核心必須遵循 ZX_PRIORITY_HIGH 設定和核心「必須」停用已標記的 VMAR 中所有的動態重回功能。

ZX_PRIORITY_DEFAULT 設定沒有特定意義，也沒有 可以尊重的尤其系統允許核心，主要目的為 以便將 ZX_PRIORITY_HIGH 要求擴展到更廣泛的範圍 已標示為 ZX_PRIORITY_DEFAULT。

雖然一律允許超過應用程式，但如果位址空間從 如果部分 ZX_PRIORITY_HIGH VMAR 沒有任何值，核心應 您從未套用設定檔時，狀態會維持不變。

資訊查詢

「zx_object_get_info」的「ZX_INFO_KMEM_STATS_EXTENDED」主題將會是 已延伸以回報額外欄位：

    // The amount of memory in VMOs that would otherwise be tracked for
    // reclamation, but has had reclamation disabled.
    uint64_t vmo_reclaim_disabled_bytes;

元件使用

使用者空間元件通常不會直接使用 zx_profile_create 等， 而是叫用 ProfileProvider 服務以下是 SetProfileByRole ProfileProvider 方法將會放寬，以接受任意控點。 而非只是執行緒

核心設計

本節說明如何將核心中的物件變更為 僅包含來自設定檔的資訊。目標是確保 可能需要知道記憶體優先順序的系統部分，才能 這樣才能有效率地進行決策在設計上盡可能有利於執行此設計 在設定檔應用程式建立時，模型會假設該設定檔 會比其他作業不常出現

減少為布林值

與重回作業相關的核心物件如下：

  • VmAspace：控制頁面表格對應關係和頁面表格回復狀態 學習。
  • VmAddressRegion - 目前並未涉及回判，而是建立 所有頁面資料表對應都是透過這個物件進行。
  • VmObject - 所有收回許可或未來網頁收回的策略時，都需要執行 VmObject。

除了 VmAddressRegion (要套用設定檔的物件) 以外， 每個物件都能查詢其任一子範圍 以及 VMAR 中有哪些 以及套用的記憶體優先順序

您可以為 VMO 區域建立多個 VMAR，並設定不同的優先順序 由套用最高的優先順序來解決

為避免在所有 VMAR 中重複執行長時間搜尋，物件需要 才能有效得知應用程式是否適用任何記憶體優先順序簡單好用 最初提議的導入方式，會將所有優先順序範圍升級為 完整物件。也就是說，如果 VmObject 的任何部分 系統會將整個物件視為擁有該設定檔。

這兩個實作的簡化，讓記憶體設定檔查詢作業更有效率 只需要透過物件連結傳播布林值聯集即可。

傳播

這個重組功能會停用布林值的傳播功能，是以邊緣轉場為基礎 而且數量仍在持續增加中

針對 VMAR 設定設定檔時，請考慮下列三種結果：

  1. 對這個 VMAR 的重覆動作維持不變。
  2. 宣告驚嘆號從已停用變為啟用狀態。
  3. 宣告從啟用變為停用狀態。

在第一個案例中不會直接傳播，但所有子區域仍須 即可直接清理資料，並將設定檔這項無條件週遊 須注意，因為子區域已套用其他設定檔 。

在兩種可能的參照物件轉換時，VmAspace 和 VmObject) 需要更新。

VmAspace 和 VmObject 物件會有一個布林值，而非單一布林值 取代了參照這些物件的數量物件啟用重回功能。 因此，如要判斷這些物件是否停用重述功能， 而非比較曝光次數與 0

VmObject 可能有其他需要傳播的 VmObject 父項 標記的目標因為宣告是受到計數器控制，或 當計數器轉換到零，或是從零轉換到零時，就會傳回零。

這項參考計數傳播策略可確保商家檔案變更 而且幾乎不會增加任何費用 布林值。

VmObject 轉場效果

除了傳播宣告標記外，VmObject 還需要執行 動作來更新其頁面。

如果停用回復功能，所有可回收的網頁都會 都會移到另外的頁面佇列。排入這個佇列 以及計算網頁的計算方法

同樣地，啟用重新宣告功能時，需要將網頁移回 預設佇列，使這些佇列再次成為候選者。這是 導入詳細說明 移回預設佇列中在沒有硬體存取的平台上 因為標記標記無法取得任何年齡資訊，所以年齡

實作

此實作將透過核心的一系列步驟完成 您將透過 API 的後續層進行實作

核心實作

核心物件的建議設計變更能完全實作 支援在不變更任何項目的情況下，設定記憶體優先順序 行為這會對多個 CL 執行，並在核心中使用 單元測試。

核心 API 變更

ZX_INFO_KMEM_STATS_EXTENDED 查詢需要具備相當特殊權限的系統 而且很少使用，全都在樹狀圖中因此，這項查詢 在單一 CL 中修改，而沒有多階段結構體演變。

更新設定檔 API 和說明文件，並將個人資料系統呼叫連結至 先前實作的核心支援zx_profile_create 系統呼叫及其 相關聯的設定結構 (zx_profile_info_t) 是特殊權限系統 呼叫，因此同樣可以在單一 CL 中修改。

ProfileProvider 變更

擴充 ProfileProvider 的實作，支援指定方法 .profiles 中的記憶體優先順序

將 ProfileProvider FIDL API 變更為可取用任意帳號，而非僅 。這是在放寬 API 一節後終止的 相容性。

媒體遷移

與媒體相關元件的相關設定檔將變更 memory_priority，ZX_PRIORITY_HIGH，所有媒體元件將 將這些設定檔套用至根 VMAR 後，方法與套用相同 加入討論串

一旦確認設定檔有效運作現有的硬式編碼核心後， 您可以移除解決方法。

成效

提議的核心設計與 核心，不過目前的暫存方法無法 且永久的 VMAR 和 VMO 將無法套用。因此，如果希望 從這個做法到個人資料，您應該完全免人工管理 功能與核心行為，包括 CPU 和記憶體用量。

安全性考量

設定檔的使用行為以及設定記憶體優先順序的功能，皆取決於 不需要根工作控制代碼因此，任何與環境相關的安全考量 阻斷服務攻擊等同於現有的阻斷服務攻擊 ProfileProvider 的可能性。

測試

大部分測試可聚焦於個別的 核心和設定檔供應商實作項目，並經過一些整合測試 驗證完整的使用路徑

說明文件

設定檔物件、相關 syscall 和 FIDL 通訊協定的說明文件 「 」即將更新。

替代方案

VMAR 上的屬性或同等項目

與其使用設定檔物件，直接設定屬性或同等元素 即可指出其優先順序這可避免 簡化了使用者空間用量， 使用 ProfileProvider。

使用這個方法時，本身就沒有辦法限制 優先順序。雖然任何元件已能分配任意記憶體 執行阻斷服務後，這不一定是理想的做法，而且會停用 可能會使「恢復」是提升成效的一種方法 這也使得一般民眾的困境。

某些形式的客製化存取控制可以解決這個問題 但現在使用設定檔的好處已撤銷。

透過 taint 推論

除了使用者空間直接標示以外，您也可以假設期限內都設有期限 執行緒需要期限記憶體存取權，並將存取的任何記憶體標示為高 優先順序。這不需要變更使用者空間，但需要 每個位址空間都具有一個以上的期限 所標示的對應或對應 / VMO 等項目 就會引發這個執行緒。

過度標示是不佳的做法，因為並非所有期限執行緒都具有相同的記憶體延遲時間 而非所有位址空間。延遲娛樂的意義 無法預先提出錯誤，因此在最糟糕的情況下，期限執行緒可能會 所以總是錯過了期限，所以不可再錯。

使用延遲標記配置時，也不清楚項目會如何取消標示。

將 memory_priority 套用至執行緒

memory_priority 欄位可能會 定義時會看到解譯內容，且優先度為 套用於根層級 VMAR

儘管這樣可以簡化 ProfileProvider 通訊協定和 可以防止使用者和核心 未來的效率高效率的元件 位於位址空間一個子區域的延遲時間機密資料 也可以只將設定檔套用至重要區域，這個 不關鍵的資料仍將考慮進行重新收回，這也很有幫助 記憶體用量

單一優先順序欄位

可以重複使用相同的執行緒優先順序 priority 欄位，而非 加入額外的 memory_priority 欄位這會產生理論 簡化了設定結構，但現在需要 如為其他記憶體和排程器優先順序不同時建立的

展開 ALWAYS_NEED 提示

目前已有 API 可用於使用 ALWAYS_NEED 和 在 VMO 或 VMAR 上使用 DONT_NEED 個提示。這些屬性目前只適用於 使用呼叫器支援的 VMO，但可延伸至匿名 VMO。

只是擴充語意來涵蓋匿名 VMO 有助於留下一些缺口：

  • ALWAYS_NEED 不保證不需要重新宣告，因為這是提示。
  • 由於系統仍在追蹤年齡，因此網頁可能仍需要存取錯誤資料。
  • 不會停用頁面表格重組功能。
  • 僅適用於現有的對應。

內部實作可以解決這些限制 與主要提案描述很類似，但 API 本身 兩個基本問題

主要提案有一個清楚的方式，可讓您知道何時重新啟用重新回復功能 將設定檔套用至所有 VMAR (或只套用到根 VMAR)含提示 無法移除 ALWAYS_NEED，因為 DONT_NEED 比復原更強大 ALWAYS_NEED。

提供提示給 API 才是真正的動力，不然是因為 因此無法存取任何 VMAR 或 VMO工作政策或 也可用來控制提示的作用 也需要設計