| RFC-0245：VMO 預先擷取 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 在 VMOs 中預先擷取資料的作業，以便準備讀取存取作業。 |
| 問題 | |
| 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 上擁有寫入權限，但如果是針對某些可執行資料，則可能沒有這項權限。第二，如果範圍日後只會用於讀取，則積極執行寫入時複製並分配頁面，這不但不必要，還會浪費記憶體。
目前，Starnix 受到第一個缺點的影響，因為它使用了只讀的 pager 支援 VMOs。PREFETCH 作業可解決上述兩項缺點，同時保留 COMMIT 的預期優點。
相關人員
協助人員：
cpu@google.com
審查者：
adamperry@google.com、dworsham@google.com
諮詢：
rashaeqbal@google.com
社會化：
這項功能是 Starnix 和虛擬記憶體團隊討論後所產生。
需求條件
應將 PREFETCH 作業新增至 VMOs，如 ZX_VMO_OP_PREFETCH，以及 VMARs，如 ZX_VMAR_OP_PREFETCH。這些作業只應要求各自的句柄的 READ 權限，並應執行必要的工作，以便日後的讀取作業只需執行最少的工作。因此，預先擷取可能會：
- 要求範圍內使用者分頁機器人提供任何缺少的頁面
- 解壓縮範圍內的任何頁面
- 針對 VMAR，請為範圍內的任何頁面建立硬體頁面表
設計和實作
核心 VM 內部已具備支援此功能的大部分工具，而實作方式主要是透過新 API 標記。因此，這項作業可以實作於一個 (如果 VMO 和 VMAR 實作項目分開，則為兩個) 小型 CL，包括任何相關測試和文件等。
成效
這項異動不應影響任何現有功能的成效，並可透過現有基準進行驗證。
安全性考量
在邏輯上，預先擷取與使用者在整個範圍內手動讀取的情況相同。除了需要使用 READ 權限而非 WRITE 權限之外，其餘規定和限制都與 COMMIT 相同，因此沒有任何新的安全考量。
測試
我們會在核心測試套件中新增測試，驗證系統是否支援 PREFETCH 作業，並正確觸發使用者 pager 要求。
從使用者空間測試其他方面 (例如 PREFETCH 觸發解壓縮作業) 相當困難，因為這些系統會刻意在效能方面向使用者提供透明資訊。由於效能導向的單元測試本質上不穩定，尤其是在模擬器執行時，因此會盡可能使用核心單元測試來測試這些行為。
替代方案
變更 COMMIT 以模擬讀取
除了導入 PREFETCH 作業之外，現有的 COMMIT 作業也可以變更語意，以模擬讀取。雖然這對 Starnix 用途來說已足夠，但其他現有使用者確實需要寫入模擬功能，並且要能及早分配頁面，以免在日後的寫入作業中發生錯誤和配置問題。
繼續使用 ALWAYS_NEED
Starnix 目前會使用 ALWAYS_NEED 作業，解決缺少 PREFETCH 作業的問題。ALWAYS_NEED 會執行與 PREFETCH 相同的初始動作，也就是擷取任何遺漏的頁面並解壓縮等。與 PREFETCH 不同的是，它會額外指出，如果可能，就不要回收這類記憶體。這會導致系統記憶體壓力，並可能增加發生 OOM 或使用者體驗降低的機率。
其他 zx_vmar_map 選項
除了支援 VMAR 作業之外，您也可以透過 ZX_VM_MAP_RANGE_PREFETCH 等其他選項，在建立對應時支援預先擷取。這項最佳化功能可避免在建立對應項目後，需要發出 PREFETCH 作業。
目前尚不清楚是否需要避免額外的系統呼叫，而這個 RFC 不希望排除 zx_vmar_map 中的額外支援，但需要超出範圍的獨立動機，並可在必要時透過後續提案完成。