From owner-svn-src-head@FreeBSD.ORG Fri Feb 20 00:26:06 2009 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2ABD106564A; Fri, 20 Feb 2009 00:26:06 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 4B9E58FC24; Fri, 20 Feb 2009 00:26:06 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local ([192.168.254.200]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n1K0Q2RU011497; Thu, 19 Feb 2009 17:26:02 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <499DF89A.2030703@samsco.org> Date: Thu, 19 Feb 2009 17:26:02 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: John Baldwin References: <200902192228.n1JMSn2Q009472@svn.freebsd.org> <200902191739.46808.jhb@freebsd.org> In-Reply-To: <200902191739.46808.jhb@freebsd.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.2 required=3.8 tests=ALL_TRUSTED,BAYES_00, HOT_NASTY autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r188833 - in head/sys: kern nfsclient sys X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 00:26:07 -0000 John Baldwin wrote: > On Thursday 19 February 2009 5:28:49 pm John Baldwin wrote: >> Author: jhb >> Date: Thu Feb 19 22:28:48 2009 >> New Revision: 188833 >> URL: http://svn.freebsd.org/changeset/base/188833 >> >> Log: >> Enable caching of negative pathname lookups in the NFS client. To avoid >> stale entries, we save a copy of the directory's modification time when >> the first negative cache entry was added in the directory's NFS node. >> When a negative cache entry is hit during a pathname lookup, the parent >> directory's modification time is checked. If it has changed, all of the >> negative cache entries for that parent are purged and the lookup falls >> back to using the RPC. This required adding a new cache_purge_negative() >> method to the name cache to purge only negative cache entries for a given >> directory. >> >> Submitted by: mohans, Rick Macklem, Ricardo Labiaga @ NetApp >> Reviewed by: mohans > > Together with the previous two changes I measured a 30% drop in the number of > RPCs for a kernel build (no modules): > > x nfs.old > + nfs.new > +------------------------------------------------------------------------------+ > | + x | > | + x | > | + x | > | + x | > | + x | > | + x | > | + x | > | + x | > | + x | > | + x | > | + x | > | + xx| > | + xx| > | + xx| > |++ xx| > |++ xx| > |+++ xx| > |+++ xx| > |+++ xx| > |+++ xxx| > | A A|| > +------------------------------------------------------------------------------+ > N Min Max Median Avg Stddev > x 30 250515 252053 251393 251352.13 362.86492 > + 30 173990 175930 175117 175011.87 474.44092 > Difference at 95.0% confidence > -76340.3 +/- 218.321 > -30.3718% +/- 0.0868584% > (Student's t, pooled s = 422.354) > > The majority of the drop was in the number of LOOKUP RPCs performed: > > x nfs.old > + nfs.new > +------------------------------------------------------------------------------+ > | + x | > | + x | > | + x | > | + x | > | + x | > | + x | > | + x | > | + x | > | + x | > | + x | > | + x | > | + xx| > | + xx| > | + xx| > | + xx| > |+++ xx| > |+++ xx| > |+++ xx| > |+++ xx| > |+++ xxx| > | A| A|| > +------------------------------------------------------------------------------+ > N Min Max Median Avg Stddev > x 30 116997 118613 117898 117887.47 372.34733 > + 30 40791 42782 41975 41846.5 481.79805 > Difference at 95.0% confidence > -76041 +/- 222.565 > -64.503% +/- 0.188794% > (Student's t, pooled s = 430.565) > > The old client performed 0 GETATTR RPC calls during the test. The new client > performs a mix of GETATTR and ACCESS calls. One of the worries was that the > client might now perform more RPC calls due to not priming the access cache, > but this is not true in this test. This next histogram is for combined totals > of ACCESS and GETATTR calls: > > x nfs.attr.old > + nfs.attr.new > +------------------------------------------------------------------------------+ > | + + x x | > | + + + + + x xxx xx | > | +++++++++ + x x xxx xx | > |+ ++++++++++ + + xxxx xxxxxxxxxx| > ||_______M_A________| |__MA__| | > +------------------------------------------------------------------------------+ > N Min Max Median Avg Stddev > x 30 90823 90898 90858 90859.633 19.496212 > + 30 90494 90792 90537 90543.467 50.121737 > Difference at 95.0% confidence > -316.167 +/- 19.6573 > -0.347973% +/- 0.0216348% > (Student's t, pooled s = 38.0282) > > With the new client, of the ~90k ACCESS + GETATTR calls are now split into > approximately 94% GETATTR and 6% ACCESS versus 0% GETATTR and 100% ACCESS. > > All of these changes are more the product of other folks who deserve the credit > moreso than myself. > These graphs are fun, but are useless without more information on the characteristics of the server and the NFS connections. Scott