lkml.org 
[lkml]   [1998]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Not much rust here; patch to try
From
Date
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

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.034 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site