<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 9/25/2020 12:17 PM, Amy Smith via
      openssl-users wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:1392765568.800823.1601061423996@mail.yahoo.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div class="yahoo-style-wrap" style="font-family:Helvetica Neue,
        Helvetica, Arial, sans-serif;font-size:13px;">I mmap the file
        which server will send (to eliminate disk performance).<br>
      </div>
    </blockquote>
    <br>
    In general, this won't work.  In fact, it may make it *harder* to
    eliminate disk performance from a measurement.<br>
    <br>
    First, of course, mmap() isn't magic.  The data has to be read off
    the disk at some point.  The only question is when.<br>
    <br>
    Second, mmap() does not necessarily (and probably does not) read the
    data immediately.  It sets up the paging tables so that those areas
    of virtual memory are paged to/from the corresponding parts of the
    file.  Just as for a page that has been kicked out of RAM into swap
    space, the first access to a page causes the page to be read.<br>
    <br>
    If you do a plain read() then you can be pretty confident that when
    the read() returns the data has been read off the disk and into
    RAM.  The same is *not* true of mmap().  If you mmap() a file and
    then start to access it, the disk I/O will be in-line with your
    accesses.<br>
    <br>
    mmap() may eliminate a memory-to-memory copy of the data, since
    read() probably does not do the disk I/O directly into your
    process's buffer, but mmap() might.  (Or, a bit more precisely, your
    mapping might point to the same page that the kernel is using for
    its disk buffer.)<br>
    <br>
    Of course any particular implementation could do things a bit
    differently, but that's my perception of how it's usually done.<br>
    <pre class="moz-signature" cols="72">-- 
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris</pre>
  </body>
</html>