From owner-svn-src-stable-7@FreeBSD.ORG Wed Apr 8 14:02:52 2009 Return-Path: Delivered-To: svn-src-stable-7@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE9651065679; Wed, 8 Apr 2009 14:02:52 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 98C208FC1A; Wed, 8 Apr 2009 14:02:52 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 26C5146B35; Wed, 8 Apr 2009 10:02:52 -0400 (EDT) Date: Wed, 8 Apr 2009 15:02:52 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Stephen McKay In-Reply-To: <200904080430.n384UGWw043589@svn.freebsd.org> Message-ID: References: <200904080430.n384UGWw043589@svn.freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, svn-src-stable-7@freebsd.org Subject: Re: svn commit: r190837 - in stable/7/sys: . contrib/pf dev/ath/ath_hal dev/cxgb kern X-BeenThere: svn-src-stable-7@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for only the 7-stable src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 14:02:53 -0000 On Wed, 8 Apr 2009, Stephen McKay wrote: > Author: mckay > Date: Wed Apr 8 04:30:16 2009 > New Revision: 190837 > URL: http://svn.freebsd.org/changeset/base/190837 > > Log: > MFC r187460: Add a limit on namecache entries. Obviously, having a limit is a good idea, but I wonder if we should use some more mature scheme to limit entries. At the very least, using UMA zone limits may help memory being dedicated to cache entries without being able to actually use it (i.e., extra entries in the UMA cache above the desiredvnodes limit). Similarly, the cost of different cache entries is different -- long entries cost much, much more than short ones, because we use two bucket sizes. Perhaps this means that we should separately count long and short entries, and short ones should contribute less towards the limit than long ones? Finally, I think it would be a good idea to do a bit of real-world profiling on memory efficiency of the name cache: how much memory is wasted when assumptions about short/long are wrong, and could we retune lengths, limits, hash bucket counts, etc, to work better in practice? Robert N M Watson Computer Laboratory University of Cambridge > > Approved by: re (kib) > > Modified: > stable/7/sys/ (props changed) > stable/7/sys/contrib/pf/ (props changed) > stable/7/sys/dev/ath/ath_hal/ (props changed) > stable/7/sys/dev/cxgb/ (props changed) > stable/7/sys/kern/vfs_cache.c > > Modified: stable/7/sys/kern/vfs_cache.c > ============================================================================== > --- stable/7/sys/kern/vfs_cache.c Wed Apr 8 03:53:20 2009 (r190836) > +++ stable/7/sys/kern/vfs_cache.c Wed Apr 8 04:30:16 2009 (r190837) > @@ -495,6 +495,12 @@ cache_enter(dvp, vp, cnp) > if (!doingcache) > return; > > + /* > + * Avoid blowout in namecache entries. > + */ > + if (numcache >= desiredvnodes * 2) > + return; > + > if (cnp->cn_nameptr[0] == '.') { > if (cnp->cn_namelen == 1) { > return; >