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

RFC-0181：Lockless Discardable VMO
狀態已接受
區域
  • Kernel
說明

允許讀取和寫入處於未鎖定狀態的可捨棄 VMO。
問題
Gerrit 變更
作者
審查人員
提交日期 (年-月-日)2022-05-18
審查日期 (年-月-日)2022-08-03

編輯這份 RFC

編輯 RFC 中繼資料

摘要

無鎖可捨棄 VMO 是可捨棄 VMO 的子類型，即使未鎖定，也能存取。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 的系統呼叫旗標需要透過 VMO 建立作業傳遞，並成為內部 VMO 的旗標。

現有的可捨棄 VMO 實作項目會在 VMO 由一對相關程式碼路徑解除鎖定時，明確導致錯誤 (這些路徑會檢查可捨棄狀態，並在解除鎖定時產生錯誤)。這些檢查只需要擴充，如果屬於 LOCKLESS 變體，就不會產生故障。

內部可捨棄清單上可捨棄 VMO 的移動方式也需要稍微變更。由於無鎖定 VMO 可能隨時都有要捨棄的頁面，而不只是自上次捨棄後鎖定的頁面，因此捨棄後必須將這些頁面留在可捨棄清單中。

如果是回收變更，系統會忽略 ZX_VMO_OP_ALWAYS_NEED 的範圍，並一律升級為完整的 VMO。系統會建立個別的可捨棄清單，並將提示的 VMO 放在該清單中。這個清單會從 ALMOST_OOM 壓力下逐出。ZX_VMO_OP_DONT_NEED 會

  • 如果 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 - Update requirements of ZX_VM_ALLOW_FAULTS for lockless discardable VMOs.

缺點、替代方案和未知事項

原始可捨棄的 RFC 說明瞭使用原子作業進行最佳化，可大幅提升效能。這種做法有兩個缺點：

  1. 核心和使用者空間之間的原子 API 是未開發的領域，探索起來相當複雜，因此原始提案中並未納入。
  2. 即使鎖定頁面很有效率，但仍不需要，而且實際上違反了我們對這些 VMO 的記憶體需求，即隨時可捨棄。

既有技術和參考資料

無