c - mmap 请求的内存大小对可用内存有什么影响？

Question

我知道 mmap 请求的内存在读取或写入之前不会实际使用。所以在下面的测试用例中:

int main()
  {
  char *A=mmap(NULL,1073741824/4, PROT_WRITE|PROT_READ,MAP_PRIVATE|MAP_ANONYMOUS,-1,0); 
  *A='a';
  char *B=mmap(NULL,1073741824/4, PROT_WRITE|PROT_READ,MAP_PRIVATE|MAP_ANONYMOUS,-1,0);
  *B='b';
  char *C=mmap(NULL,1073741824/4, PROT_WRITE|PROT_READ,MAP_PRIVATE|MAP_ANONYMOUS,-1,0);
  *C='c';
  char *D=mmap(NULL,1073741824/4, PROT_WRITE|PROT_READ,MAP_PRIVATE|MAP_ANONYMOUS,-1,0);
  *D='d'
  char *E=mmap(NULL,1073741824/4, PROT_WRITE|PROT_READ,MAP_PRIVATE|MAP_ANONYMOUS,-1,0);
  }

我假设其他程序可用的内存只减少了 16k (4 x 4096)，我是否正确？我没有看到使用 free() 时可用内存有更多减少，所以我假设是这样。

在这种情况下，假设我有一个应用程序通常使用 10MB 内存，但在极少数情况下可能突然需要高达 1GB(尽可能少的延迟)。一开始就映射 1GB 内存是可行的解决方案吗？据推测，虽然只使用了 10MB，但剩余的 990MB 可供其他应用程序使用。当需要 1GB 的罕见情况发生时，我认为与必须 malloc 或 realloc 相比，延迟会少得多。

当不再需要额外的 990MB 时，将 mremap 到 10MB 然后再映射回 1GB 以释放不再立即需要的 990MB 是否是一个可行的解决方案，但仍然可以为下次提供即时访问？我假设这会比 realloc 操作快得多？

我这里的一些假设可能是不正确的。我试图更好地了解 mmap 如何影响可用内存，以及 mremap 与使用 malloc 和 realloc 的性能影响。

以上内容基于现代 linux 内核，使用 gcc，假设 4k 页面大小和超出此范围的可移植性，不是重要的优先事项。

Answer 1

对于运行 Linux 的大多数处理器，您是正确的。一个 GB 空间的 mmap 将只占用几 KB。它比您的 16kb 多，因为必须分配“页表”以跟踪您分配的内存地址，但很多。

现代 malloc 通常会几乎直接使用 mmap 进行大型分配，因此如果您 malloc 一个巨大的空间，您将获得几乎相同的空间效果与直接使用 mmap 一样......可能(但不能保证)。

您可能应该做的一件事是将 MAP_NORESERVE 添加到您的标志(如果已定义)以确保空间实际上没有分配到某处。在 Linux 上，此标志通常几乎没有(或没有)影响，但对于最近内核的特定配置，mmap 将分配在交换中，除非你给这面旗帜。

但是请注意，某些 Unix(我认为是 Linux 下的某些处理器类型)您将无法分配尽可能多的地址空间。如果 mmap 被拒绝，您应该准备好使用较小的映射重试。

最后一件事，如果您对巨大的空间进行 mmap，而 Linux 稍后发现它的订阅量过多，它会终止进程。确保您有过多 的交换空间。您可以通过在/tmp 上拥有 30GB tmpfs(具有 8GB RAM)来证明这一点。