From owner-freebsd-current Tue May 6 01:13:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA24170 for current-outgoing; Tue, 6 May 1997 01:13:31 -0700 (PDT) Received: from critter.dk.tfs.com ([140.145.230.252]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA24162; Tue, 6 May 1997 01:13:26 -0700 (PDT) Received: from critter (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.5/8.8.5) with ESMTP id JAA02942; Tue, 6 May 1997 09:39:40 +0200 (CEST) To: Terry Lambert cc: current@FreeBSD.ORG From: Poul-Henning Kamp Subject: Re: DOC: NAME CACHE USAGE In-reply-to: Your message of "Mon, 05 May 1997 13:59:15 PDT." <199705052059.NAA16562@phaeton.artisoft.com> Date: Tue, 06 May 1997 09:39:39 +0200 Message-ID: <2940.862904379@critter> Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <199705052059.NAA16562@phaeton.artisoft.com>, Terry Lambert writes: >With all of Poul's puttering around in the name cache code (I still >think the cache data should be a pointer into the directory vnode >page where the actual name is, instead of making a copy of the name >in another buffer, considering the directory vnode must be in core >for there to be a cache reference, especially after his changes), I >thought it would be the right time to post this. This would waste storage for two reasons: 1. The size of the namecache structure is 36 bytes, which means that we can tack another 28 bytes onto the malloc allocation for free. This covers most of the names we ever see. 2. Copying the name away means that the directory vnodes doesn't have to have any pages cached to be useful. Think of a heavily used directory "/usr/local/lib/this/weird/path" With your suggestion we would have to have at least a page for each of the 5 directories for the namecache to work. >This is a document that I made prepatory to doing some work to move >the cache lookup and entry out of the FS specific code and into common >code, so that you wouldn't even have to make VOP calls if you got >cache hits. This design offers the bonus of making the FS code itself >smaller for each FS, and by making the code more bullet proof by making >the usage entirely uniform across all FS's. This is a nice idea, but not well thought out. If you were to do that, you would rob the filesystems of the control they have today to expire cached data at this time, leaving filesystems like union, nfs and null no other option than disabling cacheing entirely. >I haven't really been >able to pursue this work because it's all I can do to track current >and repair conflicts on my existing changes 8-(. (chorus) How nice the world would be, How perfect the world would be, If you all would listen more to me! :-) >It should also provide some usage information to Poul so that he can >better direct his efforts to optimize common cases. I think even Terry has misunderstood what "optimizing the namecache" means. I'll leave it as an excercise to the reader :-) Poul-Henning PS: there are a number of errors in your table. For instance cache_purge is called by vgone(), which covers many more cases than you document. Please don't post wrong information. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail.