| RFC-0181：无锁式舍弃 VMO | |
|---|---|
| 状态 | 已接受 |
| 领域 |
|
| 说明 | 允许对处于已解锁状态的可舍弃 VMO 执行读写操作。 |
| 问题 |
|
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2022-05-18 |
| 审核日期（年-月-日） | 2022-08-03 |
总结
无锁定的可舍弃 VMO 是可舍弃 VMO 的子类型。在此类 VMO 中，即使未锁定，这些 VMO 也可以被访问。系统仍可能随时舍弃 VMO，并且用户必须能容忍数据突然完全丢失的情况。为了提高激励用例中的使用率，VMO 提示操作进行了扩展，以涵盖可舍弃的 VMO。
设计初衷
跟踪是一种希望尽可能减少性能开销并生成大量数据爆发的工作负载。由于锁定和解锁会产生开销，当前的可舍弃 VMO 不适合执行此操作。使用常规匿名 VMO 的当前缺点是，由于生成的数据量激增，跟踪可能会导致系统出现 OOM。
跟踪引擎能够容忍任意数据丢失。也就是说，跟踪 VMO 可以任意停用，即使在读取或写入过程中也不会导致问题，除了跟踪数据丢失之外。此外，最好的做法是丢失部分轨迹数据，而不是整个系统 OOM。
允许在解锁状态下使用可舍弃的 VMO 解决了所有这些问题，因为：
- 通过跟踪被舍弃的 VMO 内容，可以避免系统 OOM。
- 写入跟踪记录 VMO 不会产生额外的开销。
- 跟踪已经能够容忍数据丢失，并且会将 VMO 舍弃操作视为数据丢失。
虽然跟踪系统可以容忍数据丢失，但最好仅在需要时舍弃跟踪，以避免 OOM。没有机制可以控制内核何时对可舍弃的 VMO 执行回收，或者如何平衡舍弃 VMO 与其他形式的回收方法之间的平衡。为了提高跟踪记录生成的可靠性，同时又不影响 OOM 预防，我们希望通过某种方式通知内核，以便仅在需要时从这些跟踪记录中回收资源。
利益相关方
教员：
待定
审核者：
待定
咨询人员：
待定
社交：
eieio@ 和 rashaeqbal@
设计
创建标记
无锁定可舍弃 VMO 是常规可舍弃 VMO 的子类型，应通过将选项 ZX_VMO_DISCARDABLE_LOCKLESS 传递给 zx_vmo_create（而不是常规的 ZX_VMO_DISCARDABLE 选项）来创建。已创建的可舍弃 VMO 仍会以解锁状态启动，唯一的区别在于，在解锁状态下，对 VMO 的读写操作将会成功，而不会产生错误。
控制回收
VMO 范围操作 ZX_VMO_OP_DONT_NEED 和 ZX_VMO_OP_ALWAYS_NEED 将扩展其 API 定义，以涵盖可舍弃的 VMO，而不仅仅是由分页器支持的 VMO。
锁定行为
虽然无锁定的可舍弃对象无需锁定即可使用，但仍然可以通过 ZX_VMO_OP_LOCK 和相关操作进行锁定。锁定的行为类似于常规的可舍弃 VMO，在锁定状态下，内容无法舍弃。
实现
ZX_VMO_DISCARDABLE_LOCKLESS 的系统调用标志需要在创建 VMO 的过程中向下传递，并成为内部 VMO 中的标志。
现有的可舍弃 VMO 实现会在通过一些相关代码路径检查可舍弃状态而解锁 VMO 时明确导致故障，并在解锁状态下生成错误。这些检查只需进行扩展，以便在它是锁型变体时不会生成故障。
内部可舍弃列表中的可舍弃 VMO 的移动也需要略微更改。由于无锁定 VMO 可能总是有要舍弃的页面，而不仅仅是自上次舍弃后已锁定的页面，因此在舍弃这些页面后，需要将它们保留在可舍弃列表中。
对于收回更改，ZX_VMO_OP_ALWAYS_NEED 的范围将被忽略，并始终提升为完整的 VMO。系统将创建单独的可舍弃列表，并在其中放置提示的 VMO。此列表将在 ALMOST_OOM 的压力下逐出。ZX_VMO_OP_DONT_NEED将会
- 立即舍弃 VMO（如果其已解锁）
- 将 VMO 移至常规舍弃列表（如果尚未执行此操作）。
无锁定可舍弃 VMO 在映射时不需要 ZX_VM_ALLOW_FAULTS 标志。
所有这些都可以作为 fuchsia.git 的单个小型 CL 完成，没有其他依赖项。
性能
我们预计 VMO 操作不会对性能产生任何影响，并且会在已是 Slowpath 场景的情况下添加一项额外的布尔值检查。
安全注意事项
无
隐私注意事项
无
测试
测试将添加到 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- 更新了ZX_VM_ALLOW_FAULTS对无锁定可舍弃 VMO 的要求。
缺点、替代方案和未知情况
原始可舍弃的 RFC 描述了使用原子化进行优化，该过程可以提供大部分所需的性能提升。这种方法存在两个缺点：
- 内核和用户空间之间的原子 API 不受约束，并且是一个需要探索的复杂空间，因此未在原始方案中实现。
- 即使锁定页面非常高效，也仍然不需要锁定页面，实际上会破坏这些 VMO 绝对随时可舍弃的内存需求。
早期技术和参考资料
无