Messages in this thread | | | Subject | Re: Not much rust here; patch to try | From | (Kevin Buhr) | Date | 21 Jul 1998 15:12:32 -0500 |
| |
Bill Hawes <whawes@star.net> writes: > > My kernel is heavily patched :-), but I think the relative lack of rust > may be largely due to setting inode-max to scale with memory size. For > an 8M system I have inode-max set to 1024, which nicely limits the > fraction of both inode and dcache memory.
Instead of monkeying with this artificial limit can we *please* just try harder to free inodes when we actually need memory? My patch:
ftp://mozart.stat.wisc.edu/pub/misc/patch-freeinodes.README ftp://mozart.stat.wisc.edu/pub/misc/patch-2.1.110.freeinodes2
demonstrates that this is possible and works.
The patch doesn't actively attack fragmentation, and it doesn't artificially choke the icache size on low-memory machines. All it does is free inodes with great enthusiasm in the "do_try_to_free_page" loop when memory gets tight, letting the cache grow without a hard limit otherwise. Yet, despite this simple premise, it still works great on low-memory machines, and it works great on high-memory machines. It makes the icache and dcache act like caches are supposed to: they grow when needed, then shrink when not.
Having just tested it against a vanilla 2.1.110 kernel using Bill M.'s test, I can say that it seems to solve his problem in spades. With "mem=6M" on an unloaded machine, pre- and post-find compile times of ~1m10 and ~3m47 respectively under the vanilla kernel became pre- and post-find compile times of ~1m10 and ~1m20 under my patched kernel. (The slight increase is due to dcache growth, which isn't as aggressively freed as the icache---it's not normally as much of a problem.)
Having used this patch (or something like it) since the 2.1.50s to keep my low-memory machine up for weeks and weeks at a time, I can confidently say that my patched kernels are rust-proofed, in sharp contrast to many of the stock kernels I've tried.
Even if you dislike some aspects of the patch and hate others (I know I do), it still represents the conceptually Right Thing To Do(TM).
(I happen to think active defragmentation of these caches isn't a bad idea either, but we get twice the gain for half the pain by implementing something like the above first.)
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
| |