Date: Thu, 24 Apr 1997 12:26:21 +0200 From: Poul-Henning Kamp <phk@dk.tfs.com> To: Michael Hancock <michaelh@cet.co.jp> Cc: Poul-Henning Kamp <phk@dk.tfs.com>, fs@freebsd.org Subject: Re: the namei cache... Message-ID: <736.861877581@critter> In-Reply-To: Your message of "Thu, 24 Apr 1997 19:13:44 %2B0900." <Pine.SV4.3.95.970424183951.12757D-100000@parkplace.cet.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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? we would have to traverse either the all the hash lists, or the LRU lists to locate the entries. >> 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? +64 bytes in the namecache structure :-( >> Benefit: >> We don't rely on the hash to level things out for us. > >What's wrong with relying on the hash? It's not needed. >> 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. Which will lock out some other random number of vnodes (ie directories), where as the new scheme will lock only (the already locked directory we're looking in. -- 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?736.861877581>