Date: Tue, 6 May 1997 11:37:12 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: phk@dk.tfs.com (Poul-Henning Kamp) Cc: terry@lambert.org, phk@dk.tfs.com, current@FreeBSD.ORG Subject: Re: DOC: NAME CACHE USAGE Message-ID: <199705061837.LAA19004@phaeton.artisoft.com> In-Reply-To: <1053.862940611@critter> from "Poul-Henning Kamp" at May 6, 97 07:43:31 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >The total 64 explains an incresed limit, but not a removal of the > >limit. > > think; optionally: read the code. I have read your code. I understand that you expand the size of the cache structure. I don't see huge wins from the change in my testing; can you post benchmarks showing that your reorganization is a win? Preferreably you will either choose to use target FS hiearchies containing names shorter than or equal to NCHNAMLEN, or you will not make cache entries in your new code for names that are not cached in the old code so that you do not skew the results. > >and only supporting up to 4 bytes for statistics (ignore the useless > >serial number filed -- you have the vnode pointer for that) fits you > >in 32 bytes instead of 64. > > Yes, except that the serial number isn't useless so it doesn't. It gets incremented in TOUCH() if statistics are enabled. However, it's value is not used for comparison or display. Like the direct inode references to the inode number which is never set in the LOCKF_DEBUG, it has no intrinsic value. > >The locality of reference model which requires the vnode to be available > >can likewise require its pages to be available. Local to a directory > >is local to a directory, and it matters not who allocates the pages > >which must be present for a cache hit: whether they are allocated to > >the cache block or they are allocated to the vnode referenced by the > >cache block is irrelevant. > > Wow, what a statement. > > Well, back to the subject: Allocating five pages when 5 x 64 bytes will > do is not efficient no matter how you twist it or the english language. > > In particular not when we are seing machines with 40000+ vnodes. If the directory has a lot of use, it will be getting cache misses as well, and the pages will be in core. If the whole directory is in the cache, then there are no space savings from the copy. > >The point is for each FS consumer to manage the cache, rather than each > >FS managing the cache. For the FS's you note, they qualify as FS > >consumers. There's no dichotomy there. > > ...and consequently, no point to your idea either. WRONG. You assume (incorrectly) that my statement applies equally for cache entry as well as for invalidation. It does not. A cache entry for a union FS vnode backed by an underlying FS's vnode is perfectly valid. It is only the invalidation case (which you raised) that is an issue. > Terry, please don't even bother answering, it's so painfully obvious > that you don't know what you're talking about, and I'm certainly > not going to spend any more time on you in this thread, so you will > be wasting your air. > > Ohh, and your contribution/bullshit ratio is approaching zero. Yet again, you ask for comments and shout down the commentors. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705061837.LAA19004>