From owner-freebsd-fs Thu Apr 24 03:13:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA28568 for fs-outgoing; Thu, 24 Apr 1997 03:13:56 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA28563 for ; Thu, 24 Apr 1997 03:13:53 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id KAA13250; Thu, 24 Apr 1997 10:13:44 GMT Date: Thu, 24 Apr 1997 19:13:44 +0900 (JST) From: Michael Hancock To: Poul-Henning Kamp cc: fs@freebsd.org Subject: Re: the namei cache... In-Reply-To: <1284.861810934@critter> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 23 Apr 1997, Poul-Henning Kamp wrote: > > I've been sticking my nose in the namei cache again, and that got me > wondering. > Consider this: > > We add a linked list to vnodes that represent directories > and hook all the cache entires that are relative to that > directory onto that list (sorted by name, or maybe LRU ?), > rather than finding them through the hash list. > Benefit: > We can release the cache entries at the time we recycle the > vnode, instead of the lazy release when we stumble across > an invalid cache entry, resulting in a better cache utilization. Why can't this be done now? > Benefit: > We can do away with the v_id field, unless other parts of > the kernel need it. That would be nice. Our vnodes are pretty big, 112 bytes? > Benefit: > We don't rely on the hash to level things out for us. What's wrong with relying on the hash? > > Benefit: > We can lock with finer and more logical granularity (ie. per vnode) > in the cache than we could otherwise do. It doesn't give you logical vnode granularity, but you could lock on buckets. > Neutral: > We still keep the LRU list around to reclain little used > cache entries. > > Almost neutral: > We save the storage for the hash-table but the vnode becomes 4 > bytes bigger. This is close to a break even, since the size > of the hash table is found from desiredvnodes... > I think hashing is still a better way of doing it. Regards, Mike Hancock