From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 5 00:09:44 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D7A716A4CE for ; Wed, 5 Nov 2003 00:09:44 -0800 (PST) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEA1F44005 for ; Wed, 5 Nov 2003 00:09:42 -0800 (PST) (envelope-from alc@cs.rice.edu) Received: from localhost (localhost [127.0.0.1]) by cs.rice.edu (Postfix) with ESMTP id CCADD4AA56; Wed, 5 Nov 2003 02:09:41 -0600 (CST) Received: from cs.rice.edu ([127.0.0.1]) by localhost (cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10033-01-91; Wed, 5 Nov 2003 02:09:37 -0600 (CST) Received: by cs.rice.edu (Postfix, from userid 19572) id C70154AA89; Wed, 5 Nov 2003 02:09:37 -0600 (CST) Date: Wed, 5 Nov 2003 02:09:37 -0600 From: Alan Cox To: Vivek Pai Message-ID: <20031105080937.GA9687@cs.rice.edu> References: <1066789354.21430.39.camel@boxster.onthenet.com.au> <20031022082953.GA69506@rot13.obsecurity.org> <1066816287.25609.34.camel@boxster.onthenet.com.au> <20031022095754.GA70026@rot13.obsecurity.org> <1067183332.3f9bece4c0cf4@webmail.cs.princeton.edu> <3FA2C43E.3030204@cs.princeton.edu> <3FA7EF77.5010808@cs.princeton.edu> <20031104221455.I9997@odysseus.silby.com> <3FA897E7.5020103@cs.princeton.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FA897E7.5020103@cs.princeton.edu> User-Agent: Mutt/1.3.28i X-Virus-Scanned: by amavis-20030616-p5 at rice.edu cc: freebsd-hackers@freebsd.org Subject: Re: Update: Debox sendfile modifications X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2003 08:09:44 -0000 On Wed, Nov 05, 2003 at 01:25:43AM -0500, Vivek Pai wrote: > Mike Silbersack wrote: > >On Tue, 4 Nov 2003, Vivek Pai wrote: > >>The one other aspect of this is that sf_bufs mappings are maintained for > >>a configurable amount of time, reducing the number of TLB ops. You can > >>specify the parameter for how long, ranging from -1 (no coalescing at > >>all), 0 (coalesce, but free immediately after last holder release), to > >>any other time. Obviously, any value above 0 will increase the amount of > >>wired memory at any given point in time, but it's configurable. > > > >Ah, I missed that point. Did your testing show the caching part of the > >functionality to be significant? > > I think it buys us a small gain (a few percent) under static-content > workloads, and a little less under SpecWeb99, where more time is spent > in dynamic content. However, it's almost free - the additional > complexity beyond just coalescing is hooking into the timer to free > unused mappings. I think it's reasonable to expect a more pronounced effect on i386 SMP. In order to maintain TLB coherence, we issue two interprocessor interrupts _per_page_ transmitted by sendfile(2). Alan