Messages in this thread | | | Subject | Re: Strange interrupt behaviour | From | (Kevin Buhr) | Date | 12 Jul 1998 13:17:57 -0500 |
| |
Andi Kleen <ak@muc.de> writes: > > alan@lxorguk.ukuu.org.uk (Alan Cox) writes: > > 2.1.10x isnt usable on a server with 16Mb. It eventually fragments > > itself to death normally death by dcache fragmentation of main > > memory. I suspect a 32Mb box will simply last longer rather than > > survive indefinitely. > > Using the slab allocator directly for the dcache could help a lot (instead > of the kmalloc emulation, which is more prone to fragmentation). The problem > is to fit the variable length filename into the slab object cache paradigm. > > One possible solution would be to add a default array of e.g. 16 or 32bytes > to the dentry object itself, and only fall back to a separate allocation > if the filename exceeds that [SQL databases use similar techniques for text > fields]
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
| |