| RFC-0181：无锁可丢弃 VMO | |
|---|---|
| 状态 | 已接受 |
| 区域 |
|
| 说明 | 允许读取和写入处于解锁状态的可舍弃 VMO。 |
| 问题 |
|
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2022-05-18 |
| 审核日期（年-月-日） | 2022-08-03 |
摘要
无锁可舍弃 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 实现会明确导致故障。只需扩展这些检查，使其在遇到 LOCKLESS 变体时不再生成故障。
内部可舍弃列表上可舍弃 VMO 的移动也需要略作更改。由于无锁 VMO 可能始终有要舍弃的页面，而不仅仅是在自上次舍弃以来被锁定的情况下，因此在舍弃后需要将其留在可舍弃列表中。
对于回收更改，系统会忽略 ZX_VMO_OP_ALWAYS_NEED 的范围，并始终将其提升为完整 VMO。系统将创建单独的可舍弃列表，并将提示的 VMO 放置在该列表中。此列表将在 ALMOST_OOM 压力下被逐出。ZX_VMO_OP_DONT_NEED 将
- 如果 VMO 已解锁，请立即将其丢弃
- 将 VMO 移至常规舍弃列表（如果尚未移至）。
无锁可舍弃 VMO 在映射时不需要 ZX_VM_ALLOW_FAULTS 标志。
所有这些都可以通过一个小的 CL 完成，提交到 fuchsia.git，不依赖于其他任何内容。
性能
预计不会对 VMO 操作产生性能影响，因为仅在已有的慢速路径场景中添加了一个额外的布尔值检查。
安全注意事项
无
隐私注意事项
无
测试
测试将添加到 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- 更新了无锁可舍弃 VMO 的ZX_VM_ALLOW_FAULTS要求。
缺点、替代方案和未知因素
原始的可舍弃 RFC 描述了一种使用原子操作进行优化的方法，该方法可以提供大部分所需的性能提升。这种方法存在两个缺点：
- 内核与用户空间之间的原子 API 尚属未涉足的领域，探索起来会很复杂，因此在最初的提案中并未涉及。
- 锁定页面即使很高效，也仍然是不需要的，实际上与我们希望这些 VMO 随时可丢弃的内存需求相悖。
在先技术和参考资料
无