| 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 的写入权限，如果是针对某些可执行数据，则可能没有此类权限。其次，它会主动执行写入时复制并分配页面，但这不是必要操作，如果将来只读取范围，会浪费内存。
如今，Starnix 受到了第一个不利因素的影响，即其使用由只读分页器支持的 VMO。PREFETCH 操作可以同时解决这两个缺点，同时保留 COMMIT 的期望优势。
利益相关方
教员：
cpu@google.com
审核者：
adamperry@google.com、dworsham@google.com
咨询人员：
rashaeqbal@google.com
社交：
此功能是通过 Starnix 和虚拟内存团队讨论提出的。
要求
PREFETCH 操作应作为 ZX_VMO_OP_PREFETCH 添加到 VMO，作为 ZX_VMAR_OP_PREFETCH 添加到 VMAR。这些操作应该只需要对其各自的句柄具有 READ 权限，并且应该执行必要的工作，使未来的读取操作只需执行极少的工作。因此，PREFETCH 可能会：
- 向范围内的用户寻呼机请求任何缺失的网页
- 解压缩该范围内的所有页面
- 对于 VMAR，请为相应范围内的任何页面创建硬件分页表格
设计和实现
内核虚拟机内部件已具有支持此功能的大多数工具，并且实现在很大程度上尝试连接新的 API 标志。因此，如果 VMO 和 VMAR 实现拆分成小型 CL（包括任何相关测试和文档），则可以一或两个实现。
性能
此变更不应影响任何现有功能的性能，应使用现有基准进行验证。
安全注意事项
PREFETCH 逻辑上等同于用户在整个范围内执行手动读取。除了需要 READ 权限而不是写入权限之外，其余要求和限制与提交完全相同，因此这里没有新的安全注意事项。
测试
系统将在核心测试套件中添加相关测试，以验证是否支持 PREFETCH 操作并正确触发用户分页器请求。
很难从用户空间测试其他方面（例如 PREFETCH 触发解压缩），因为这些系统有意对用户在很大程度上透明，并影响模组的性能。由于基于性能的单元测试本质上不稳定，特别是由于模拟器执行，因此将尽可能使用内核单元测试对这些行为进行测试。
替代选项
更改 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 中的其他支持，但它需要额外的动机，这超出了范围，并可以在需要时在跟进提案中完成。