RFC-0181：無鎖定可捨棄的 VMO

RFC-0181：無鎖定的可捨棄 VMO
狀態已接受
區域
  • 核心
說明

允許讀取和寫入已解鎖公告中的可捨棄 VMO。
問題
變更
作者
審查人員
提交日期 (年/月)2022-05-18
審查日期 (年/月)2022-08-03

編輯此 RFC

編輯 RFC 中繼資料

摘要

無鎖定的 VMO 是不受鎖定的 VMO 子類型，而且即使未鎖定，仍可存取這些 VM。系統可能隨時會刪除 VMO，且使用者必須承受突然完全遺失的資料。為改善激勵用途的使用率，系統擴大 VMO 提示作業的涵蓋範圍，以便一併處理可捨棄的 VMO。

提振精神

追蹤是一種工作負載，能壓低效能負擔並產生大量資料爆發。由於鎖定和解鎖造成的負擔，目前可捨棄的 VMO 不適合用於此作業。使用一般匿名 VMO 會造成目前缺點，因為這可能會產生大量資料，進而導致系統執行 OOM。

追蹤引擎可容許任意資料遺失。也就是說，追蹤 VMO 可能會任意停用，即使在讀取或寫入期間亦不會造成問題，但不致於遺失追蹤記錄資料。此外，與整個系統 OOM 相比，這種做法更適合遺失部分追蹤記錄資料。

允許在解鎖時使用可捨棄的 VMO，就能解決下列所有問題：

  • 追蹤捨棄的 VMO 內容會避免系統 OOM。
  • 寫入追蹤記錄 VMO 不會產生額外的負擔。
  • 追蹤記錄已經可容許資料遺失，並會在資料遺失時察覺 VMO 捨棄作業。

雖然追蹤系統可容許資料遺失，但最好只在必要時捨棄 OOM 的追蹤記錄。目前，沒有任何機制可控制核心何時會在可捨棄的 VMO 執行重組，或是如何平衡捨棄 VMO 與其他形式的重建作業。為了提高產生追蹤記錄的可靠性，同時兼顧 OOM 預防措施，因此我們希望通知核心只在必要時回收這些項目。

相關人員

講師：

未定

審查者：

未定

顧問：

未定

社群媒體化：

eieio@ 和 rashaeqbal@

設計

建立旗標

無鎖定的 VMO 是一般可捨棄 VMO 的子類型，應將選項 ZX_VMO_DISCARDABLE_LOCKLESS 傳遞至 zx_vmo_create (而非一般的 ZX_VMO_DISCARDABLE 選項) 來建立。建立的免卡 VMO 仍以解鎖狀態啟動，唯一的差別在於處於未解鎖狀態的讀取與寫入 VMO 成功，而非產生錯誤。

控制資料回收

VMO 範圍作業 ZX_VMO_OP_DONT_NEED 和 ZX_VMO_OP_ALWAYS_NEED 的 API 定義將擴大範圍，涵蓋可捨棄的 VMO，而不只是透過呼叫器支援的 VMO。

鎖定行為

雖然沒有鎖定的可捨棄項目還是可以在 ZX_VMO_OP_LOCK 和相關作業中鎖定。鎖定的運作方式與一般可捨棄的 VMO 相同，鎖定內容卻無法捨棄。

實作

ZX_VMO_DISCARDABLE_LOCKLESS 的 syscall 旗標必須透過 VMO 建立程序才能傳遞，成為內部 VMO 中的旗標。

現有的可捨棄 VMO 實作會在以下情況中，檢查 VMO 是否處於可捨棄狀態，並藉由檢查相關程式碼路徑來解鎖 VMO，並且在未鎖定的情況下產生錯誤。這些檢查只需要延伸到 LOCKLESS 變數後，便不會產生錯誤。

對於內部可捨棄清單中的可捨棄 VMO，您也需要稍微變更。無鎖定的 VMO 可能隨時有需要捨棄的頁面，而不是僅限於在上次捨棄後遭鎖定的頁面，因此捨棄後，這些 VMO 必須留待捨棄的可捨棄清單。

如要進行重新宣告，系統會忽略 ZX_VMO_OP_ALWAYS_NEED 的範圍，並一律升級至完整的 VMO。系統會建立可捨棄的清單，並加上提示 VMO。系統會在 ALMOST_OOM 壓力之下移除這份清單。ZX_VMO_OP_DONT_NEED會

  • 如果 VMO 處於解鎖狀態，請立即捨棄該 VMO
  • 如果尚未將 VMO 移至一般捨棄清單，請移至該清單。

對應時，無鎖定的 VMO 不需要 ZX_VM_ALLOW_FAULTS 標記。

這全部都可以透過單一小型 CL 至 fuchsia.git 完成，且無需使用其他依附元件。

效能

這對 VMO 作業不會造成效能影響，不過，現有的緩慢路徑情境中，會加入一個額外的布林值檢查。

安全性考量

無

隱私權注意事項

無

測試

測試會新增至 Zircon 核心測試套件。

說明文件

相關系統呼叫文件需要更新：

  • zx_vmo_create - 文件 ZX_VMO_DISCARDABLE_LOCKLESS。
  • zx_vmo_op_range - 更新 ZX_VMO_OP_ALWAYS_NEED 和 ZX_VMO_OP_DONT_NEED 支援的 VMO 類型陳述式。
  • zx_vmar_map - 針對無鎖定的 VMO 更新 ZX_VM_ALLOW_FAULTS 的規定。

缺點、替代方案和未知

原始可捨棄的 RFC 說明瞭如何使用原子序最佳化，以便將整體需要的效能提升。這種做法有兩個缺點：

  1. 核心與使用者空間之間的不可分割式 API 是未硬化的地面，不僅相當複雜，因此還難以探索，因此並未在原始提案中完成。
  2. 即使頁面效率較高，系統也並不需要鎖定頁面，而且實際上會根據這些 VMO 的記憶體需求隨時捨棄。

先前的圖片和參考資料

無