From owner-freebsd-stable@FreeBSD.ORG Thu Mar 23 23:52:40 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 AECCA16A400; Thu, 23 Mar 2006 23:52:40 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from gate.bitblocks.com (bitblocks.com [209.204.185.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6889F43D46; Thu, 23 Mar 2006 23:52:40 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost [127.0.0.1]) by gate.bitblocks.com (8.13.6/8.13.1) with ESMTP id k2NNqPS8018729; Thu, 23 Mar 2006 15:52:25 -0800 (PST) (envelope-from bakul@bitblocks.com) Message-Id: <200603232352.k2NNqPS8018729@gate.bitblocks.com> To: Matthew Dillon In-reply-to: Your message of "Thu, 23 Mar 2006 15:16:11 PST." <200603232316.k2NNGBka068754@apollo.backplane.com> Date: Thu, 23 Mar 2006 15:52:25 -0800 From: Bakul Shah Cc: alc@freebsd.org, Mikhail Teterin , 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:52:40 -0000 > : time fgrep meowmeowmeow /home/oh.0.dump > : 2.167u 7.739s 1:25.21 11.6% 70+3701k 23663+0io 6pf+0w > : time fgrep --mmap meowmeowmeow /home/oh.0.dump > : 1.552u 7.109s 2:46.03 5.2% 18+1031k 156+0io 106327pf+0w > : > :Use a big enough file to bust the memory caching (oh.0.dump above is 2.9Gb), > > :I'm sure, you will have no problems reproducing this result. > > 106,000 page faults. How many pages is a 2.9GB file? If this is running > in 64-bit mode those would be 8K pages, right? So that would come to > around 380,000 pages. About 1:4. So, clearly the operating system > *IS* pre-faulting multiple pages. ... > > 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. May be the OS needs "reclaim-behind" for the sequential case? This way you can mmap many many pages and use a much smaller pool of physical pages to back them. The idea is for the VM to reclaim pages N-k..N-1 when page N is accessed and allow the same process to reuse this page. Similar to read ahead, where the OS schedules read of page N+k, N+k+1.. when page N is accessed. May be even use TCP algorithms to adjust the backing buffer (window) size:-)