Date: Thu, 24 Apr 1997 19:13:44 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Poul-Henning Kamp <phk@dk.tfs.com> Cc: fs@freebsd.org Subject: Re: the namei cache... Message-ID: <Pine.SV4.3.95.970424183951.12757D-100000@parkplace.cet.co.jp> In-Reply-To: <1284.861810934@critter>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.95.970424183951.12757D-100000>