On Mon, Jul 31, 2000 at 03:39:51PM -0500, Oliver Xymoron wrote:
> You have to be hitting the inode cache pretty hard for this to be a big
> deal, right? And that cache is already hidden behind the dcache, right?
> I think the saving memory side of your argument is better than the cache
> footprint one..
Smaller cache footprint is always a win. E.g. when your user program and
the kernel manage to run both in L2 for a working set you save a lot of time.
The key to that is small overall memory/cache footprint of the kernel
(2.0 was much better in that than 2.4)
The dcache hash is of course improved in the same way, I just didn't do
a benchmark for it.
AFAIK the main hard hitter of the inode cache is knfsd when its file handle
cache is trashing and it is walking trees all the time
(although 2.4 should be a much better in that than 2.2 because it does not
need to regenerate the full path in most cases)
> Perhaps there's another clever way to do this - is there a way to make the
> list heads partially overlap? That is &hash[i-1].next == &hash[i].prev?
> Sick, I know, but it might not mean a separate list implementation, just
> special initialization - HASHLISTHEAD().
You always need to special case the single pointer, no way around that.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:35 EST