根据手册：mmap_
MAP_NORESERVE
不要为此映射保留交换空间。保留交换空间时，可以保证可以修改映射。如果没有保留交换空间，如果没有可用的物理内存，可能会在写入时获得 SIGSEGV。
据我了解，如果将常规文件映射到虚拟地址范围，则不需要任何交换空间。只是MAP_ANONYMOUS可能需要一些交换空间。
那么，始终为常规文件添加MAP_NORESERVE标志是否正确？mmap
更新：
更具体地说，总是MAP_NORESERVE在 mmap 中为常规文件添加标志是否正确，何时MAP_SHARED使用？
据我了解，如果将常规文件映射到虚拟地址范围，则不需要任何交换空间。只是
MAP_ANONYMOUS可能需要一些交换空间。
这取决于 mmap 标志。如果映射了常规文件，MAP_PRIVATE则内存区域从文件初始化，但不受文件支持。如果系统决定交换其任何页面，则系统将需要交换空间来进行此类映射。
那么，始终为常规文件添加
MAP_NORESERVE标志是否正确？mmap
指定任何映射都不是错误的。MAP_NORESERVE这只是一个关于您希望对程序行为有什么保证的问题。
此外，您似乎从错误的方向看这个。如果一个特定的映射永远不需要交换空间，那么系统将不会为它保留交换空间，不管标志是什么。在这种情况下使用它并没有什么坏处MAP_NORESERVE，但它也无济于事，那有什么意义呢？
另一方面，如果您想确保映射不会因为使用而失败，MAP_NORESERVE那么最合适的做法是避免使用该标志。如果您愿意，您可以完全忽略它的存在，事实上，如果您想要最大的可移植性，您应该这样做，因为MAP_NORESERVE它是 POSIX 未指定的 Linux 扩展。
更新：
据我了解，您断言您可以重复地观察现有文件的现有范围与MAP_SHAREDto require的成功映射MAP_NORESERVE。也就是说，仅在是否MAP_NORESERVE指定方面不同的两次此类映射尝试将以您可以预测和可靠重现的方式为您产生不同的结果。
我觉得这令人惊讶，甚至是可疑的。我不希望页表映射到常规文件的现有区域的进程虚拟地址空间的页面与交换空间有任何关联，因此我不希望系统尝试为此类页面保留任何交换空间它建立了一个映射，尽管有标志。如果您真正观察到不同的行为，那么我会将其归因于库或内核错误，您应该对此提出问题。
例如，考虑一下 GNU libc 手册，它明确指出内存映射可以大于物理内存和交换空间，但根本没有记录特定MAP_NORESERVE于 Linux 的文件。
话虽如此，为任何给定的内存映射指定（在 Linux 上）是不正确的。MAP_NORESERVE但是，我希望它对于常规文件的现有区域的映射毫无意义MAP_SHARED，因此我认为常规使用该标志进行此类映射不是好的做法——更不用说最佳做法了。另一方面，如果指定该标志可以解决库或内核错误，否则会干扰建立某些映射，那么我认为没有特别的理由避免这样做，但我希望每次这样的使用都附有解释原因的文档注释使用该标志。