Date: Wed, 23 Apr 1997 17:55:34 +0200 From: Poul-Henning Kamp <phk@dk.tfs.com> To: fs@freebsd.org Subject: the namei cache... Message-ID: <1284.861810934@critter>
next in thread | raw e-mail | index | archive | help
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. Benefit: We can do away with the v_id field, unless other parts of the kernel need it. Benefit: We don't rely on the hash to level things out for us. Benefit: We can lock with finer and more logical granularity (ie. per vnode) in the cache than we could otherwise do. 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... Comments ? Have I overlooked something fundamental ? -- 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. Future will arrive by its own means, progress not so.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1284.861810934>