使用 mmap 保留地址空间的开销答案

【问题标题】：overhead of reserving address space using mmap使用 mmap 保留地址空间的开销
【发布时间】：2013-02-13 14:54:55
【问题描述】：

我有一个程序经常使用海量数组，其中内存是使用mmap分配的

是否有人知道在提交内存之前大量分配地址空间的典型开销，无论是使用MAP_NORESERVE 分配还是使用稀疏文件支持空间？ It5 让我印象深刻，mmap 不能免费，因为它必须为分配的空间创建页表条目。在实现我正在考虑的算法之前，我想对这种开销有所了解。

显然，答案将取决于平台，我对 x64 linux、sparc solaris 和 sparc linux 最感兴趣。我认为 1mb 页面的可用性使得 sparc 的开销比 x64 少。

【问题讨论】：

我根本不用担心开销。听起来像premature optimization。
@camelccc 真正的开销在您访问分配的内存时开始。也就是说，用于处理产生的中断并为其分配物理内存。在当前的高端系统上，64Kb 通常约为 60µs。您可能对高频交易中的零分配编程感兴趣。

标签： mmap

【解决方案1】：

mmap 的开销取决于您使用它的方式。当您以适当的方式使用它时，它通常可以忽略不计。

在linux内核中，mmap的操作可以分为两部分：

所以分配大量内存使用mmap就不多介绍了开销比小的。

所以你应该在每次分配内存时尽可能的大。（避免多次小mmap）

您可以明确提供起始地址（如果可能）。这可以在内核中节省一些时间来寻找足够大的可用空间。

如果您的应用程序是多线程程序。 您应该避免同时调用mmap。那是因为地址空间受到读写锁的保护，而 mmap 总是使用写锁。在这种情况下，mmap 延迟将增加几个数量级。

此外，mmap 只创建映射而不创建页表。页面被触摸时在页面错误处理程序中分配。页面错误处理程序将获取保护地址空间的读取器锁，并且还会影响mmap 的性能。

在这种情况下，您应该始终尝试重用您的大数组，而不是再次使用 munmap 和 mmap。（避免页面错误）

【讨论】：