linux - mmap 如何提高文件读取速度？

Question

假设地址空间可以覆盖文件，在我看来，mmap 只是分配了一块与将要读取的文件一样大的内存，并在它们对应的块之间创建了 1 对 1 的关系。但是，为什么这样做会加快文件读取速度？看来，要想真正得到文件的内容，还是得去磁盘，读取磁盘上的所有字节。

与malloc'ing相同大小的内存并手动将整个文件读入malloc'ed区域相比，它有什么区别？

Answer 1

mmap工作方式不同。它是预期的并适应程序的访问模式。此外，可以通过 madvise 设置特定策略。进一步微调使用。

有关如何更彻底的讨论 mmap在需求分页环境中工作，请在此处查看我的答案:Which segments are affected by a copy-on-write?因为它还谈到了 mmap 的使用
mmap是程序执行的命脉，通过 execve等。阿尔。所以，你可以打赌它很快。作为旁注，具有讽刺意味的是 malloc实际使用匿名mmap以及。

但是，对于这里的讨论，特别要注意带有 mmap 的文件的“后备存储”(即分页磁盘)。对比做 malloc和 read(2)
与 mmap ，内存区域的后备存储是文件本身。该区域将页面直接映射到内核的文件系统缓冲区页面 [它们已经统一了很长时间]。因此，不需要像 read(2) 那样从内核文件系统缓冲区页面到应用程序页面的 [浪费] 复制。 .

当您这样做时malloc/read ，您仍然拥有上述页面，但是，现在 malloc 区域在分页/交换磁盘上有一个后备存储。因此，页面缓冲区是 mmap 的两倍.正如我所提到的，读取完成后必须将数据复制到该区域中。

此外，就性能而言，进行大量读取并不是最佳选择。块中的推荐大小约为 64 KB [取决于文件系统]。

当您进行大量读取时，您的程序在完成之前无法启动。如果文件的大小大于物理内存，系统会读入你的 malloc 区域，并且会浪费性地开始将较早的页面刷新到分页磁盘，为靠近文件末尾的页面腾出空间，直到整个文件被读入。

换句话说，当这个大的预读发生时，应用程序正在等待[并且什么也不做]。对于 [比如说] 60 GB 的文件，启动时间会很明显。

如果您的文件确实足够大，您甚至会耗尽分页磁盘上的空间(即 malloc 返回 NULL)。

对于 mmap ，不存在这样的问题。当您映射文件时，您可以立即开始使用它。它将直接从该区域的后备存储(再次是文件系统中的文件)根据需要“故障”。而且，如果您有 [说] 1 TB 文件，mmap处理得很好。

此外，您可以通过 madvise(2) 控制映射策略。和 posix_madvise(2)逐页或任何页面范围，包括整个文件。 madvise syscall 相对轻量级，因此可以大量使用它。这是一个提示，但不会执行会延迟应用程序的 I/O。如果 I/O 开始预读提示，它由内核作为后台事件完成。

你甚至可以告诉系统很快就会需要给定的页面[并且系统以此作为预取它的提示]或者你可以告诉系统不再需要该页面[并且系统将释放页面缓冲内存]。

您可以对整个文件说“顺序访问”，这意味着系统将知道自动进行预读，以及释放不再需要的页面(即，如果您当前正在访问页面 N，然后系统释放Nk之前的任何页面)

当你做 read(2) ，无法告诉系统不再需要给定的内核 FS 页缓冲区。它们会徘徊，直到物理 RAM 填满 [或超过给定的限制]，这会给整个内存系统增加压力。

在实践中，使用 read ，我已经看到在应用程序移动到文件的不同部分或完全不同的文件后很长一段时间内，用于 FS 缓冲区的内存量仍然很高。事实上，我已经看到一个 I/O 密集型应用程序使用了如此多的缓冲区，以至于导致无关的 [空闲] 进程的页面被盗并刷新到分页磁盘。当我停止 I/O 应用程序时，firefox 需要几分钟的时间才能重新调入页面并再次响应。

我为常规读取与 mmap 做了一些广泛的基准测试。从中，mmap 可以提高某些应用程序的速度。

在此处查看我的回答:read line by line in the most efficient way *platform specific*

在我这样做之前，我对 mmap 的好处持怀疑态度，但基准测试表明 mmap 是赢家。

另外，如果你正在做 read(2) (速度)对比 fgets ，如果给定的行跨越读取缓冲区边界(即缓冲区的最后 50 个字符具有 80 个字符行的前 50 个字节)，您可能会因必须执行的缓冲区移位而陷入困境。

请注意，在此链接页面中的评论中，还有另一个指向 pastebin 的链接指向我的基准程序的更高版本，并且结果太大而无法发布在上述 SO 答案中，该答案对各种进行了基准测试和比较 madvise选项