From owner-svn-src-head@FreeBSD.ORG Mon Feb 23 15:34:35 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 C9BC31065752; Mon, 23 Feb 2009 15:34:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0E5928FC16; Mon, 23 Feb 2009 15:34:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (pool-98-109-39-197.nwrknj.fios.verizon.net [98.109.39.197]) by cyrus.watson.org (Postfix) with ESMTPSA id 9458B46B55; Mon, 23 Feb 2009 10:34:33 -0500 (EST) Received: from localhost (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id n1NFY2ks016392; Mon, 23 Feb 2009 10:34:27 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Scott Long Date: Mon, 23 Feb 2009 10:19:50 -0500 User-Agent: KMail/1.9.7 References: <200902192228.n1JMSn2Q009472@svn.freebsd.org> <200902191739.46808.jhb@freebsd.org> <499DF89A.2030703@samsco.org> In-Reply-To: <499DF89A.2030703@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902231019.51340.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 23 Feb 2009 10:34:27 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.2/9031/Mon Feb 23 08:19:18 2009 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx 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: Mon, 23 Feb 2009 15:34:41 -0000 On Thursday 19 February 2009 7:26:02 pm Scott Long wrote: > 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): > > These graphs are fun, but are useless without more information on the > characteristics of the server and the NFS connections. In this case the server was an Isilon. Other folks using similar patches have reported similar results against NetApp filers. My testing was more to do a final sanity check of my tweaking of others patches so they could be integrated into the tree. Note that the primary purpose of the graphs was to show that the difference in RPC counts was statistically meaningful across a run of several tests. Also, note that the graphs are not measuring differences in wall-time, etc. (which could certainly be very sensitive to the server and other factors such as load on the network) but are merely changes in the counts of RPC requests submitted by the client. Since NFS is largely "stateless" without server-to-client callbacks, I presume that the mix of RPC requests submitted by a client are determined mostly by the NFS client rather than the server. -- John Baldwin