From owner-freebsd-stable@FreeBSD.ORG Thu Mar 23 23:32:06 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0158C16A400 for ; Thu, 23 Mar 2006 23:32:06 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.colo.erols.net (noop.colo.erols.net [207.96.1.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8167E43D49 for ; Thu, 23 Mar 2006 23:32:05 +0000 (GMT) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.colo.erols.net with local (Exim 4.52 (FreeBSD)) id 1FMZHg-0006ff-Np; Thu, 23 Mar 2006 18:32:04 -0500 Date: Thu, 23 Mar 2006 18:32:04 -0500 From: Gary Palmer To: Matthew Dillon Message-ID: <20060323233204.GA14996@in-addr.com> Mail-Followup-To: Matthew Dillon , stable@freebsd.org References: <200603211607.30372.mi+mx@aldan.algebra.com> <200603231403.36136.mi+mx@aldan.algebra.com> <200603232048.k2NKm4QL067644@apollo.backplane.com> <200603231626.19102.mi+mx@aldan.algebra.com> <200603232316.k2NNGBka068754@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200603232316.k2NNGBka068754@apollo.backplane.com> Cc: stable@freebsd.org Subject: Re: Reading via mmap stinks (Re: weird bugs with mmap-ing via NFS) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2006 23:32:06 -0000 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