Date: Tue, 06 May 1997 19:43:31 +0200 From: Poul-Henning Kamp <phk@dk.tfs.com> To: Terry Lambert <terry@lambert.org> Cc: phk@dk.tfs.com (Poul-Henning Kamp), current@FreeBSD.ORG Subject: Re: DOC: NAME CACHE USAGE Message-ID: <1053.862940611@critter> In-Reply-To: Your message of "Tue, 06 May 1997 10:17:21 PDT." <199705061717.KAA18718@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199705061717.KAA18718@phaeton.artisoft.com>, Terry Lambert writes: >> This would waste storage for two reasons: >> >> 1. The size of the namecache structure is 36 bytes, which means that >> we can tack another 28 bytes onto the malloc allocation for free. >> This covers most of the names we ever see. > >Well, I guess this assumes FreeBSD never moves to a SLAB allocator, >right? only if it proves superior, and I seriously doubt that is going to happen any time soon (but by all means, submit patches!) >The total 64 explains an incresed limit, but not a removal of the >limit. think; optionally: read the code. >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. >> 2. Copying the name away means that the directory vnodes doesn't have >> to have any pages cached to be useful. Think of a heavily used >> directory "/usr/local/lib/this/weird/path" With your suggestion we >> would have to have at least a page for each of the 5 directories >> for the namecache to work. > >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. >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. 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. -- 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?1053.862940611>