为什么mmap（）的是比顺序IO快？ [英] Why mmap() is faster than sequential IO?

问题描述

  

可能重复：结果
   mmap（）的对比阅读块

我听说（读它的地方，在互联网上）的的mmap（）比顺序IO速度更快。它是否正确？如果是的话，为什么它是更快？

• 的mmap（）不是顺序读取。


• 的mmap（）已经从磁盘本身一样阅读（）确实
来取

• 的映射区不连续的 - 所以没有DMA
（？）。

所以的mmap（）实际上应该是比慢从文件中读取（）？其中我假设以上是错的？

解决方案

  

我听说（读它在互联网上的某个地方）的mmap（）的是比顺序IO速度更快。它是否正确？如果是的话，为什么它是更快？

它可以是 - 有优点和缺点，如下表所示。 的当你真正有理由关心，总是既标杆的。

从实际IO效率且不说，也有方式产生影响时，需要做应用code轨道的I / O，并执行数据处理/代，即有时可以影响性能相当显着。

  

1）MMAP（）不是顺序读取。
  2）mmap（）的具有为已读从磁盘本身同样取（）不
  3）映射区不连续的 - 所以没有DMA（）

？。
  
  

所以mmap（）的实际上应该是从一个文件慢于阅读（）？其中我假设以上是错的？

1）是错误的... 的mmap（）分配相应的文件内容的虚拟地址空间...只要在地址空间中的页面被访问的区域，物理内存中找到备份的虚拟地址和相应的磁盘内容是有故障的成RAM。因此，在其内容被从磁盘完成的顺序匹​​配的访问的顺序。这是一个懒惰的I / O机制。如果，例如，你需要索引到一个巨大的哈希表，这是从磁盘读取，那么 MMAP ING文件，并开始做访问意味着磁盘I / O时不是按顺序完成，因此可能会导致更长的运行时间直到整个文件读入内存，但同时这是发生查找是成功和依赖的工作可以进行，如果从来没有实际需要的文件的部分他们不是阅读（允许对磁盘和内存页面的粒度，以及使用内存映射甚至当许多操作系统允许您指定有关您计划的访问模式的一些性能增强/内存效率的技巧，使他们能够前瞻性地预读或更积极地释放内存知道你是不太可能回到它）。

2）绝对真实

3）的映射区不连续是模糊的。存储器映射的区域在虚拟地址空间连续的（顺序）。我们已经讨论了磁盘I / O是上文顺序。或者，你在想别的东西吗？不管怎么说，网页被指责时，他们可能确实是使用DMA传输。

此外，还有为什么内存映射可能优于通常的其他原因，I / O：

• 有较少的复制：
  
  
  
  • 经常OS＆安培;库级程序通过一个或多个缓冲区的数据达到一个应用程序指定的缓冲区前，一个应用然后动态分配存储，然后复制从I / O缓冲到该存储，这样数据的可用文件读取完成后
  
  
  • 内存映射允许（但不强制）就地使用（你可以记录指针和可能的长度）
    
    
    
    • 继续就地风险增加后交换访问数据：文件/内存映射可能会比到它能够被解析的数据结构更详细的，所以数据访问模式在其中能有更多的延误更多的内存故障页
    
    
  
  


• 内存映射可以让应用程序把整个文件内容的可访问性，而不是担心到时读满一个缓冲区简化了应用程序的分析工作


• 申请推迟更多的网页操作系统的智慧重新数量在物理RAM在任何时间单点，有力地配合了应用程序共享直接访问磁盘缓存


• 下面的好心人的意见，使用内存映射您通常使用更少的系统调用


• 如果多个进程正在访问同一个文件，他们应该能够共享物理后备页

本也是原因 MMAP 可能比较慢 - 你读林纳斯·托瓦兹的的post这里它说的 MMAP ：

  

...页表故障一起游戏（甚至只是TLB未命中）
  开销是容易比在一个不错的复制页的成本更
  流媒体的方式...

和从另一个他的职务的：

  

  

• 相当明显安装和拆卸成本。我的意思的明显的。这之类的东西下页表干净取消映射的一切。这是簿记保持所有的映射的列表。这是取消映射的东西后所需的TLB刷新。


  

• 页面错误是昂贵的。这是映射如何被填充，这是相当缓慢的。


  

Possible Duplicate:
mmap() vs. reading blocks

I heard (read it on the internet somewhere) that mmap() is faster than sequential IO. Is this correct? If yes then why it is faster?

• mmap() is not reading sequentially.
• mmap() has to fetch from the disk itself same as read() does
• The mapped area is not sequential - so no DMA (?).

So mmap() should actually be slower than read() from a file? Which of my assumptions above are wrong?

解决方案

I heard (read it on the internet somewhere) that mmap() is faster than sequential IO. Is this correct? If yes then why it is faster?

It can be - there are pros and cons, listed below. When you really have reason to care, always benchmark both.

Quite apart from the actual IO efficiency, there are implications for the way the application code tracks when it needs to do the I/O, and does data processing/generation, that can sometimes impact performance quite dramatically.

1) mmap() is not reading sequentially. 2) mmap() has to fetch from the disk itself same as read() does 3) The mapped area is not sequential - so no DMA (?).

So mmap() should actually be slower than read() from a file? Which of my assumptions above are wrong?

1) is wrong... mmap() assigns a region of virtual address space corresponding to file content... whenever a page in that address space is accessed, physical RAM is found to back the virtual addresses and the corresponding disk content is faulted into that RAM. So, the order in which reads are done from the disk matches the order of access. It's a "lazy" I/O mechanism. If, for example, you needed to index into a huge hash table that was to be read from disk, then mmaping the file and starting to do access means the disk I/O is not done sequentially and may therefore result in longer elapsed time until the entire file is read into memory, but while that's happening lookups are succeeding and dependent work can be undertaken, and if parts of the file are never actually needed they're not read (allow for the granularity of disk and memory pages, and that even when using memory mapping many OSes allow you to specify some performance-enhancing / memory-efficiency tips about your planned access patterns so they can proactively read ahead or release memory more aggressively knowing you're unlikely to return to it).

2) absolutely true

3) "The mapped area is not sequential" is vague. Memory mapped regions are "contiguous" (sequential) in virtual address space. We've discussed disk I/O being sequential above. Or, are you thinking of something else? Anyway, while pages are being faulted in, they may indeed be transferred using DMA.

Further, there are other reasons why memory mapping may outperform usual I/O:

• there's less copying:
  • often OS & library level routines pass data through one or more buffers before it reaches an application-specified buffer, the applicaton then dynamically allocates storage, then copies from the I/O buffer to that storage so the data's usable after the file reading completes
  • memory mapping allows (but doesn't force) in-place usage (you can just record a pointer and possibly length)
    • continuing to access data in-place risks increased swapping later: the file/memory-map could be more verbose than data structures into which it could be parsed, so access patterns on data therein could have more delays to fault in more memory pages
• memory mapping can simplify the application's parsing job by letting the application treat the entire file content as accessible, rather than worrying about when to read another buffer full
• the application defers more to the OS's wisdom re number of pages that are in physical RAM at any single point in time, effectively sharing a direct-access disk cache with the application
• as well-wisher comments below, "using memory mapping you typically use less system calls"
• if multiple processes are accessing the same file, they should be able to share the physical backing pages

The are also reasons why mmap may be slower - do read Linus Torvald's post here which says of mmap:

...page table games along with the fault (and even just TLB miss) overhead is easily more than the cost of copying a page in a nice streaming manner...

And from another of his posts:

• quite noticeable setup and teardown costs. And I mean noticeable. It's things like following the page tables to unmap everything cleanly. It's the book-keeping for maintaining a list of all the mappings. It's The TLB flush needed after unmapping stuff.

• page faulting is expensive. That's how the mapping gets populated, and it's quite slow.

这篇关于为什么mmap（）的是比顺序IO快？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！