title: Understanding memory mapping conceptually
body: <p>I've already asked this question on <a href="https://cs.stackexchange.com/questions/113433/understanding-memory-mapping-conceptually">cs.stackexchange.com</a>, but decided to post it here as well. </p>
  
  <p>I've read several blogs and questions on stack exchange, but I'm unable to grasp what the real drawbacks of memory mapped files are. I see the following are frequently listed:</p>
  
  <ol>
  <li><p>You can't memory map large files (>4GB) with a 32-bit address space. This makes sense to me now.</p></li>
  <li><p>One drawback that I thought of was that if too many files are memory mapped, this can cause lower available system resources (memory) => can cause pages to be evicted => potentially more page faults. So some prudence is required in deciding what files to memory map and their access patterns.</p></li>
  <li><p>Overhead of kernel mappings and data structures - <a href="https://marc.info/?l=linux-kernel&amp;m=95496636207616&amp;w=2" rel="nofollow noreferrer">according to Linus Torvalds</a>. I won't even attempt to question this premise, because I don't know much about the internals of Linux kernel. :)</p></li>
  <li><p>If the application is trying to read from a part of the file that is not loaded in the page cache, it (the application) will incur a penalty in the form of a page-fault, which in turn means increased I/O latency for the operation.</p></li>
  </ol>
  
  <p>QUESTION #1: Isn't this the case for a standard file I/O operation as well? If an application tries to read from a part of a file that is not yet cached, it will result in a syscall that will cause the kernel to load the relevant page/block from the device. And on top of that, the page needs to be copied back to the user-space buffer.</p>
  
  <p>Is the concern here that page-faults are somehow more expensive than syscalls in general - my interpretation of what <a href="https://marc.info/?l=linux-kernel&amp;m=95496636207616&amp;w=2" rel="nofollow noreferrer">Linus Torvalds says here</a>? Is it because page-faults are blocking => the thread is not scheduled off the CPU => we are wasting precious time? Or is there something I'm missing here?</p>
  
  <ol start="5">
  <li>No support for async I/O for memory mapped files.</li>
  </ol>
  
  <p>QUESTION #2: Is there an architectural limitation with supporting async I/O for memory mapped files, or is it just that it no one got around to doing it?</p>
  
  <p>QUESTION #3: Vaguely related, but my interpretation of <a href="https://manybutfinite.com/post/page-cache-the-affair-between-memory-and-files/" rel="nofollow noreferrer">this article</a> is that the kernel can read-ahead for standard I/O (even without fadvise()) but does not read-ahead for memory mapped files (unless issued an advisory with madvice()). Is this accurate? If this statement is in-fact true, is that why syscalls for standard I/O maybe faster, as opposed to a memory mapped file which will almost always cause a page-fault?</p>