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