| RFC-0245：VMO 預先擷取 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 在 VMO 中預先擷取資料，以準備讀取存取權。 |
| 問題 | |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2024-03-19 |
| 審查日期 (年-月-日) | 2024-04-09 |
摘要
擁有 ZX_VMO_OP_COMMIT 的唯讀類似項目，可填入即將讀取存取的 VMO。
提振精神
現有的 COMMIT 作業 (ZX_VMO_OP_COMMIT 和 ZX_VMAR_OP_COMMIT) 是供使用者使用的效能工具。使用者可藉此指出要使用的 VMO 或 VMAR 範圍，讓核心更有效率地大量分配所有頁面，避免日後發生許多錯誤。
由於 COMMIT 的目的是模擬寫入作業，因此目前有兩項缺點。 首先，這項作業需要 VMAR 和/或 VMO 的 WRITE 權限，如果這是某些可執行檔資料，您可能沒有這項權限。其次，它會主動執行寫入時複製作業並分配頁面，如果日後只會讀取範圍，這就沒有必要，而且會浪費記憶體。
目前 Starnix 受到第一個缺點的影響，也就是使用唯讀分頁支援的 VMO。PREFETCH 作業可解決上述兩項缺點，同時保留 COMMIT 的優點。
利害關係人
協助人員：
cpu@google.com
審查者：
adamperry@google.com、dworsham@google.com
已諮詢：
rashaeqbal@google.com
社交：
這項功能是 Starnix 團隊和虛擬記憶體團隊討論的結果。
需求條件
應將 PREFETCH 作業新增至 VMO，如 ZX_VMO_OP_PREFETCH 和 VMAR，如 ZX_VMAR_OP_PREFETCH。這些作業應只需要各自控制代碼的 READ 權限，並執行必要工作，讓日後的讀取作業盡量減少工作量。因此，PREFETCH 可能會：
- 要求範圍內使用者呼叫器中任何遺失的頁面
- 解壓縮範圍內的任何頁面
- 如果是 VMAR，請為範圍內的任何頁面建立硬體頁面表格
設計與實作
核心 VM 內部已具備支援這項功能的大部分工具，而實作作業主要是要導入新的 API 標記。因此，這項功能可以實作在一個或兩個 (如果 VMO 和 VMAR 實作項目分開) 小型 CL 中，包括任何相關測試和文件等。
效能
這項異動不應影響任何現有功能的效能，並會以現有基準進行驗證。
安全性考量
PREFETCH 在邏輯上等同於使用者在範圍內執行手動讀取作業。除了需要 READ 權限而非 WRITE 權限之外，其餘需求和限制與 COMMIT 完全相同，因此這裡沒有新的安全性考量。
測試
測試會新增至核心測試套件，以驗證系統是否支援 PREFETCH 作業，並正確觸發使用者分頁要求。
由於這些系統刻意對使用者保持高度透明，因此很難從使用者空間測試其他層面，例如 PREFETCH 觸發的解壓縮作業 (效能除外)。以效能為基礎的單元測試本質上不穩定，尤其是在模擬器執行時，因此我們會盡可能使用核心單元測試來測試這些行為。
替代方案
將 COMMIT 變更為模擬讀取
現有的 COMMIT 作業可以變更語意來模擬讀取作業，而不必導入 PREFETCH 作業。雖然這對 Starnix 用途來說已足夠，但其他現有使用者確實需要寫入模擬，並積極分配頁面，以避免日後寫入時發生錯誤和分配。
繼續使用 ALWAYS_NEED
Starnix 目前使用 ALWAYS_NEED 作業，解決缺少 PREFETCH 作業的問題。ALWAYS_NEED 會執行與 PREFETCH 相同的初始動作，也就是帶入任何遺失的頁面並解壓縮等。與 PREFETCH 不同的是，ALWAYS_NEED 會額外聲明，如果可以的話，不應回收這項記憶體。這會造成系統記憶體壓力，並可能提高 OOM 發生機率或導致使用者體驗不佳。
其他 zx_vmar_map 選項
除了支援 VMAR 作業外，PREFETCH 也可在對應建立時透過其他選項 (例如 ZX_VM_MAP_RANGE_PREFETCH) 支援。這項最佳化作業可避免在建立對應後發出 PREFETCH 作業。
目前尚不清楚是否需要避免額外的系統呼叫，且本 RFC 不希望排除 zx_vmar_map 中的額外支援，但需要獨立的動機，這超出範圍，且可在後續提案中視需要完成。