总是在 mmap 中为常规文件添加 MAP_NORESERVE 标志？

Question

根据mmap的手册：

MAP_NORESERVE

不要为此映射保留交换空间。 保留交换空间时，可以保证可以修改映射。 当没有保留交换空间时，如果没有可用的物理内存，则可能会在写入时获得 SIGSEGV。

据我了解，如果将常规文件映射到虚拟地址范围，则不需要任何交换空间。 只有MAP_ANONYMOUS可能需要一些交换空间。

那么，总是在mmap为常规文件添加MAP_NORESERVE标志是否正确？

更新：

更具体地说，当使用MAP_SHARED时，总是在 mmap 中为常规文件添加MAP_NORESERVE标志是否正确？

Answer 1

据我了解，如果将常规文件映射到虚拟地址范围，则不需要任何交换空间。 只有MAP_ANONYMOUS可能需要一些交换空间。

这取决于 mmap 标志。 如果使用MAP_PRIVATE映射常规文件，则内存区域从文件初始化，但不受文件支持。 如果系统决定换出其任何页面，则系统将需要用于此类映射的交换空间。

那么，总是在mmap为常规文件添加MAP_NORESERVE标志是否正确？

为任何映射指定MAP_NORESERVE并没有错。 这只是您希望对程序行为有什么保证的问题。

此外，你似乎从错误的方向看这个。 如果一个特定的映射永远不需要交换空间，那么无论标志如何，系统都不会为其保留交换空间。 在这种情况下使用MAP_NORESERVE并没有什么坏处，但它也无济于事，那么有什么意义呢？

另一方面，如果您想确保映射不会因使用MAP_NORESERVE而失败，那么最合适的做法是避免使用该标志。 如果您愿意，您可以完全忽略它的存在，事实上，如果您想要最大的可移植性，您应该这样做，因为MAP_NORESERVE是 POSIX 未指定的 Linux 扩展。

---

更新：

据我了解，您断言您可以通过MAP_SHARED重复观察现有文件的现有范围的成功映射，以要求MAP_NORESERVE 。 也就是说，仅在是否指定了MAP_NORESERVE两个此类映射尝试将为您产生不同的结果，您可以预测并可靠地重现。

我觉得这令人惊讶，甚至令人怀疑。 我不希望页表映射到常规文件现有区域的进程虚拟地址空间的页面与交换空间有任何关联，因此我不希望系统尝试为这些页面保留任何交换空间它建立了一个映射，尽管有标志。 如果您真的观察到不同的行为，那么我会将其归因于库或内核错误，您应该提出问题。

例如，考虑一下 GNU libc 手册，它明确指出内存映射可以大于物理内存和交换空间，但根本没有记录 Linux 特定的MAP_NORESERVE 。

话虽如此，为任何给定的内存映射指定MAP_NORESERVE并没有错（在 Linux 上）。 但是，我希望它对于常规文件现有区域的MAP_SHARED映射毫无意义，因此我认为经常使用该标志进行此类映射的做法不是很好——更不用说是最佳实践了。 另一方面，如果指定该标志可以绕过干扰建立某些映射的库或内核错误，那么我认为没有特别的理由避免这样做，但我希望每个这样的使用都伴随着解释原因的文档注释使用该标志。