Date: Sun, 20 Jun 2004 12:52:14 -0400 From: Mikhail Teterin <mi+kde@aldan.algebra.com> To: Dan Nelson <dnelson@allantgroup.com> Cc: current@freebsd.org Subject: Re: read vs. mmap (or io vs. page faults) Message-ID: <200406201252.14255@aldan> In-Reply-To: <20040620154120.GC5040@dan.emsphone.com> References: <200406200343.03920@aldan> <20040620154120.GC5040@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Thanks! -mi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200406201252.14255>