I looked at this a long time ago, implementing exactly what you talked
about. What I discovered is that dcache/dfilename fragmentation was
*nothing* compared to the fragmentation caused by inodes. If you do
the math, you discover that, at worst, the dcache sucks up a few dozen
pages. Under the current scheme, the inodes suck up a few hundred.
I have a patch that puts inodes and dentries (though, not the
filenames) into the slab cache and more aggressively frees inodes.
I've been very pleased with its performance, though it's not
kernel-ready. Anyway, it's something to play with; I've already
posted something about it on the list:
ftp://mozart.stat.wisc.edu/pub/misc/patch-freenodes.README
ftp://mozart.stat.wisc.edu/pub/misc/patch-2.1.106-freenodes
ftp://mozart.stat.wisc.edu/pub/misc/patch-2.1.108-freenodes
I use this to keep my 24 meg machine up for months at a time; it won't
last two days with the stock kernel. (I use the "pagecache" and
"buffermem" settings given in the "README", though. Otherwise, my
patch's default sysctl settings are way too aggressive.)
Kevin <buhr@stat.wisc.edu>
-
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.altern.org/andrebalsa/doc/lkml-faq.html