Date: Thu, 24 Apr 1997 13:59:29 -0700 From: David Greenman <dg@root.com> To: Poul-Henning Kamp <phk@dk.tfs.com> Cc: fs@freebsd.org Subject: Re: the namei cache... Message-ID: <199704242059.NAA11021@root.com> In-Reply-To: Your message of "Thu, 24 Apr 1997 22:38:54 %2B0200." <1420.861914334@critter>
next in thread | previous in thread | raw e-mail | index | archive | help
>This is what I thought, but appearantly not so. Part of the problem seems
>to be that there are multiple names pointing at the same directory ("foo"
> + N * "..") and that depletes your name-cache. With the current design
>it should probably be 1.5 .. 2 times bigger than desiredvnodes.
>
>I'm very reluctant to increase it, when entries cost 64 bytes each, and
>since data seems to indicate that 10% is stale (but we don't know how to
>find them), so we keep recycling valid entries instead.
>
>Another thing that bothers me is the size. The reason for the current
>size of 64 is the way malloc works. In reality we would get very close
>to the same efficiency from 48 bytes per entry. I may look into changing
>the way we allocate them. It would buy us 33% more entries in the same
>space.
>
>David:
> Can I get you to try one (mostly harmless) experiment on
> wcarchive ? In vfs_cache.c, where it checks the number of
> namecache entries against "desiredvnodes" could you try to use
> 2*desiredvnodes (or something similar) instead, and measure
> the difference in cache hit rate ?
I've increased kern.maxvnodes which I think should have the same effect.
This actually made things worse - a few percent lower cache hit rate. Very
odd. It might have just been a statistical anomoly. In any case, it definately
didn't improve the hit rate.
-DG
David Greenman
Core-team/Principal Architect, The FreeBSD Project
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704242059.NAA11021>