read vs. mmap (or io vs. page faults)
mi+kde at aldan.algebra.com
Sun Jun 20 16:52:38 GMT 2004
On Sunday 20 June 2004 11:41 am, Dan Nelson wrote:
= In the last episode (Jun 20), Mikhail Teterin said:
= > I expected the second way to be faster, as it is supposed to avoid
= > one memory copying (no user-space buffer). But in reality, on a
= > CPU-bound (rather than IO-bound) machine, using mmap() is
= > considerably slower. Here are the tcsh's time results:
= MADV_SEQUENTIAL just lets the system expire already-read blocks from
= its cache faster, so it won't help much here.
That may be what it _does_, but from the manual page, one gets an
impression, it should tell the VM, that once a page is requested (and
had to be page-faulted in), the one after it will be requested soon and
may as well be prefeteched (and the ones before can be dropped if memory
is in short supply). Anyway, using MADV_SEQUENTIAL is consintently
making mmap behave slightly worse, rather then have no effect.
But let's not get distracted with madvise(). Why is mmap() slower? So
much so, that the machine, which is CPU-bound using read() only uses 90%
of the CPU when using mmap -- while, at the same time -- the disk
bandwidth is also less than that of the read(). It looks to me, like a
lot of thought went into optimizing read(), but much less into mmap,
which is supposed to be faster -- less memory shuffling. Is that true,
is there something inherent in mmap-style of reading, that I don't see?
= read() should cause some prefetching to occur, but it obviously
= doesn't work all the time or else inblock wouldn't have been as high
= as 11000. For sequential access I would have expected read() to have
= been able to prefetch almost every block before the userland process
= needed it.
More information about the freebsd-current