Date: Mon, 28 Apr 1997 09:19:30 +0200 From: Poul-Henning Kamp <phk@dk.tfs.com> To: Bakul Shah <bakul@torrentnet.com> Cc: Poul-Henning Kamp <phk@dk.tfs.com>, hackers@freebsd.org Subject: Re: the namei cache... Message-ID: <238.862211970@critter> In-Reply-To: Your message of "Mon, 28 Apr 1997 01:37:44 EDT." <199704280537.BAA27601@chai.plexuscom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199704280537.BAA27601@chai.plexuscom.com>, Bakul Shah writes: >The bound is not so low as in the namei cache case but reuse >policies do matter. The point of analogy was not to duplicate what >they do but to remind you to check out the range of techniques they >use. May be some of them are useful? ... and there is no locking to consider, no reentrancy, no smp and so on. Quite different in fact. >> You obviously don't know how the name cache operates. Only names >> you lookup ends up in the cache, it's not the entire directory >> that gets put into the cache (unless you do a "ls -l" that is). "Cliff's notes to Kernel Name Cache": The most important thing is hit-rate. Everytime we have a hit we save at least one disk-access. That means that if we can get just one more hit in he namecache, we can safely spend several msec finding it. >My comment about scaling stands. Indeed, but compared to the >real< metric for name-cache efficiency, it's not terribly important. >> I wish all of these "instant-fs" specialists would read up on their >> subject matter before they jump in with their misunderstandings! > >I wish all of these "instant-optimization" specialists would do some >profiling before they start hacking with their misunderstandings! I don't know of anybody besides me who have profiled the name cache... If you check out the commit logs, you will know how long time I've been working on it... >Try not to assume that anything that does not make sense to you is >automatically meaningless. Bakul, I wasn't particularly after you with that comment, it was more pointed at the people who suggested new hash algorithms without understanding the nature of the cache and what it does for the kernel. I have no doubt you know what you talk about, but you are headed down the wrong track. The performance question is: How do we get the best hit rate from the least use of memory & CPU. I can tell you that I have not found measurable difference in cpu usage with our without the hashing, (wcarchive will probably show something though), but I have seen significant impact by upping the hit rate just a tiny fraction of a percent. Considering that fact, spending two pages on a hash table may not be the most efficient use of memory... -- 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?238.862211970>