| RFC-0181：無鎖定可丟棄的 VMO | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 允許讀取及寫入處於解鎖狀態的可捨棄 VMOs。 |
| 問題 |
|
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2022-05-18 |
| 審查日期 (年-月-日) | 2022-08-03 |
摘要
無鎖的可丟棄 VMOs 是可丟棄的 VMOs 的子類型，即使未上鎖，也允許存取。VMO 仍可能隨時遭到捨棄，使用者必須能接受資料突然完全遺失的情況。為了改善誘因用途的使用情況，VMO 提示作業已擴充至涵蓋可捨棄的 VMOs。
提振精神
追蹤是一種工作負載，希望能將效能額外負擔降至最低，並產生大量資料。由於鎖定和解鎖的額外負擔，目前可捨棄的 VMOs 不適合用於此用途。使用一般匿名 VMOs 的現行缺點是，由於產生的資料大量爆增，追蹤記錄可能會導致系統發生 OOM 問題。
追蹤引擎可容許任意資料遺失。也就是說，即使在讀取或寫入期間，追蹤 VMO 也能任意取消提交，而不會造成問題 (除了追蹤資料遺失)。此外，與讓整個系統發生 OOM 相比，讓部分追蹤資料遺失會是較佳的做法。
允許在解鎖時使用可捨棄的 VMOs，可解決所有這些問題，因為：
- 追蹤遭到捨棄的 VMO 內容，即可避免系統 OOM。
- 寫入追蹤 VMOs 不會產生額外負荷。
- 追蹤功能已可容許資料遺失，並會將 VMO 捨棄視為資料遺失。
雖然追蹤系統可容許資料遺失，但建議您只在需要時捨棄追蹤，以免發生 OOM。目前沒有任何機制可控制核心何時會對可丟棄的 VMOs 執行回收作業，也無法平衡丟棄 VMOs 與其他形式的回收作業。為了提高追蹤產生的可靠性，且不影響 OOM 防範機制，因此我們希望能夠在需要時，通知核心從這些記憶體中回收。
相關人員
協助人員：
未定
審查者：
未定
諮詢：
未定
社會化：
eieio@ 和 rashaeqbal@
設計
建立標記
無鎖定可捨棄的 VMOs 是一般可捨棄的 VMOs 的子類型，應透過將選項 ZX_VMO_DISCARDABLE_LOCKLESS 傳遞至 zx_vmo_create 來建立，而非一般 ZX_VMO_DISCARDABLE 選項。建立的可捨棄 VMO 仍會在解鎖狀態下啟動，唯一的差異在於，在解鎖狀態下，讀取和寫入 VMO 會成功，而不會產生錯誤。
控制版權聲明
VMO 範圍作業 ZX_VMO_OP_DONT_NEED 和 ZX_VMO_OP_ALWAYS_NEED 的 API 定義會擴充，涵蓋可捨棄的 VMOs，而非僅限於 pager 支援的 VMOs。
鎖定行為
雖然無鎖棄置項目可在未鎖定狀態下使用，但仍可透過 ZX_VMO_OP_LOCK 和相關作業進行鎖定。鎖定行為與一般可棄置的 VMO 相同，且在鎖定期間，內容無法棄置。
實作
ZX_VMO_DISCARDABLE_LOCKLESS 的系統呼叫標記必須透過 VMO 建立傳遞，並成為內部 VMO 中的標記。
當 VMO 遭到解鎖，並由幾個相關的程式碼路徑檢查可捨棄狀態，且在解鎖時產生錯誤時，現有的可捨棄 VMOs 實作會明確導致錯誤。這些檢查只需要擴充，如果是 LOCKLESS 變體，就不會產生錯誤。
內部可捨棄清單中可捨棄的 VMOs 移動作業也需要稍微變更。由於無鎖定 VMO 可能隨時都有頁面可棄用，而非只有在自上次棄用後才鎖定，因此這些頁面在棄用後必須留在可棄用清單中。
對於回收變更，系統會忽略 ZX_VMO_OP_ALWAYS_NEED 的範圍，並一律將其提升為完整 VMO。系統會建立可捨棄的清單，並在其中放置提示的 VMOs。系統會在 ALMOST_OOM 壓力下，將此清單從記憶體中移除。ZX_VMO_OP_DONT_NEED 會
- 如果 VMO 已解鎖，請立即丟棄
- 將 VMO 移至一般刪除清單 (如果尚未移至的話)。
在對應時，無鎖的可捨棄 VMOs 不需要 ZX_VM_ALLOW_FAULTS 標記。
這一切都可以透過單一小型 CL 完成，且不會有其他依附元件。
成效
在已是慢速路徑情境中，額外加入單一布林值檢查，對 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- 針對無鎖定可丟棄的 VMOs，更新ZX_VM_ALLOW_FAULTS的規定。
缺點、替代方案和未知事項
原始可捨棄的 RFC 說明瞭使用原子最佳化，可提供大部分的效能提升。這種做法有兩個缺點：
- 核心和使用者空間之間的 API 是未知領域，因此探索起來會相當複雜，這也是為何在原始提案中未採用這項 API 的原因。
- 即使鎖定頁面很有效率，但仍不必要，而且實際上會違背我們希望這些 VMOs 隨時可完全捨棄的記憶體需求。
既有技術與參考資料
無