Date: Wed, 02 Dec 1998 09:16:11 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Peter Jeremy <peter.jeremy@auss2.alcatel.com.au> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Name cache questions. Message-ID: <23059.912586571@critter.freebsd.dk> In-Reply-To: Your message of "Wed, 02 Dec 1998 11:08:43 %2B1100." <98Dec2.110806est.40355@border.alcanet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <98Dec2.110806est.40355@border.alcanet.com.au>, Peter Jeremy writes: >I've been studying the name cache code (in 3.0-RELEASE), trying to see >if I can improve the hit rate. Looking at the code (in kern/vfs_cache.c) >it's not clear to me how the cache is managed. In several cases, the >comments appear at variance to the code. Yes, the comments may be in variance, I havn't checked that very carefully. The namecache is not a separate entity like it used to be, it is mode like an attachment to the vnodes. The namecache entry goes when the vnodes goes (or in certain other specifically requested cases like rename and whatsnot). Negative entries have no vnode, so they must be limited by some other means. The current ncnegfactor seems to work ok, but no careful benchmarks have been done. >3) cache_lookup() includes the comment `We don't do this if the > segment name is long'. Neither cache_lookup(), nor any of its > callers appear to include code to check the segment name length > (other than to NAME_MAX). Well, we used to not cache long names. >4) cache_purge() includes the comment `If the v_id wraps around, we > need to ditch the entire cache'. The code doesn't check for > wrap-around, it simply avoids v_id == 0 and re-using the existing > v_id. (Although this appears to be adequate). Well, technically we do, but I have decided that the probability of a problem is too epsilon to be done anything about. You have to create 2^32 vnodes in mem, and then one particular vnode which has survived this entire cycle should get recycled and assigned the same v_id before you would have problems. The right way of solving this would probably be to make the v_id private per vnode, since it can only ever be used together with a pointer to the vnode. >Overall, it appears that the name cache size is controlled solely by >the vnode list - when a vnode list entry is reused, any associated >name cache entries are invalidated. Is this correct? yes. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?23059.912586571>