Re: [PATCH] New dcache / inode hash tuning patch

[torvalds@transmeta.com (Linus Torvalds)]

In article <20030301043131.7D5301058@oscar.casa.dyndns.org>,
Ed Tomlinson  <tomlins@cam.org> wrote:
>
>I wonder what would happen if you reordered the chains moving a 'found'
>dentry to the front of the chain?  If this could be done without 
>excessive locking it might help keep hot entries quickly accessable.

The original dentry code actually did that. It sucks.

The reason it sucks is not so much just the locking, but the fact that
you dirty the cache lines, which means that not only are you blowing
your cache on that CPU, you also caused the other CPU's to blow _their_
caches (the lines that are in the cache can no longer be shared) AND you
caused excessive bus traffic for the writeouts. 

In other words: it makes sense if there is one or two really hot
entries.  But it does not make sense in general.  But you might have
some heuristic that does it "every 1000 lookups" or something like that,
to avoid the problems but still statistically getting the really hot
entries closer to the top. 

This cache behaviour is, btw, something that rcu made worse - with the
pre-rcu stuff, we avoided taking the dcache locks and incrementing the
dcache counters for intermediate cached lookups, and we only did it for
the leaf entry (or misses). 

I hope that we can re-do that optimization _with_ rcu in 2.7.x.

		Linus