Date: Mon, 21 Jun 2004 15:59:33 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Dan Nelson <dnelson@allantgroup.com> Cc: current@freebsd.org Subject: Re: read vs. mmap (or io vs. page faults) Message-ID: <200406212259.i5LMxX1l036547@apollo.backplane.com> References: <Pine.BSF.4.21.0406201716191.23541-100000@InterJet.elischer.org> <200406211057.31103@aldan> <200406211952.i5LJqWSl035702@apollo.backplane.com> <200406211810.03629@misha-mx.virtual-estates.net> <20040621222631.GC86471@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:ask for 8k, but the system will fetch the next 64k of data. Problem is
:the system does nothing until you read the next 8k past the 64k
:alreqady read in, then it jumps up and grabs the next 64k. You're
:still waiting on I/O every 8th read. Ideally it would do an async
:..
:--
: Dan Nelson
: dnelson@allantgroup.com
No, this isn't true. The system places a marker 8K or 16K before the
last read block and initiates the next read-ahead before you exhaust the
first one.
For mapped data the system intentionally does not map the page table entry
for a page or two before the end of the read ahead in order to force a
page fault so it can initiate the next read ahead.
For read data the system marks a buffer near the end of the read ahead
so when read encounters it the system knows to queue then next read-ahead.
Also, for that matter, remember that the hard drives themselves generally
cache whole tracks and do their own read-ahead. This is why dd'ing a
large file usually results in the maximum transfer rate the hard drive
can do.
-Matt
Matthew Dillon
<dillon@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200406212259.i5LMxX1l036547>