Date: Thu, 23 Mar 2006 18:32:04 -0500 From: Gary Palmer <gpalmer@freebsd.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: stable@freebsd.org Subject: Re: Reading via mmap stinks (Re: weird bugs with mmap-ing via NFS) Message-ID: <20060323233204.GA14996@in-addr.com> In-Reply-To: <200603232316.k2NNGBka068754@apollo.backplane.com> References: <200603211607.30372.mi%2Bmx@aldan.algebra.com> <200603231403.36136.mi%2Bmx@aldan.algebra.com> <200603232048.k2NKm4QL067644@apollo.backplane.com> <200603231626.19102.mi%2Bmx@aldan.algebra.com> <200603232316.k2NNGBka068754@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 23, 2006 at 03:16:11PM -0800, Matthew Dillon wrote: > In anycase, this sort of test is not really a good poster child for how > to use mmap(). Nobody in their right mind uses mmap() on datasets that > they expect to be uncacheable and which are accessed sequentially. It's > just plain silly to use mmap() in that sort of circumstance. This is > a trueism on ANY operating system, not just FreeBSD. The uncached > data set test (using unmount/mount and a dataset which fits into memory) > is a far more realistic test because it simulates the most common case > encountered by a system under load... the accessing of a reasonably sized > data set which happens to not be in the cache. I thought one serious advantage to this situation for sequential read mmap() is to madvise(MADV_DONTNEED) so that the pages don't have to wait for the clock hands to reap them. On a large Solaris box I used to have the non-pleasure of running the VM page scan rate was high, and I suggested to the app vendor that proper use of mmap might reduce that overhead. Admitedly the files in question were much smaller than the available memory, but they were also not likely to be referenced again before the memory had to be reclaimed forcibly by the VM system. Is that not the case? Is it better to let the VM system reclaim pages as needed? Thanks, Gary
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060323233204.GA14996>