Re: a patch that might help on small-memory machines (was Re: 2.1 MM [was: Re: 2.2 will never come..

Kevin Buhr (buhr@stat.wisc.edu)
07 Jul 1998 12:14:17 -0500


Andrea Arcangeli <arcangeli@mbox.queen.it> writes:
>
> On 6 Jul 1998, Kevin Buhr wrote:
>
> >The patch, against 2.1.106, is a bit long for the list:
> >
> > ftp://mozart.stat.wisc.edu/pub/misc/patch-2.1.106-freeinodes
>
> I have tried it and the kernel started to make mess. No fs corruption
> though. After a lot of IO the HD continued to run. I couldn' t reboot,
> and I had to press reset. I could have applyed the patch badly since I had
> to apply it partly by hand due lots of patch reject...

Was this against kernel 2.1.108? Did the thrashing start immediately
when you booted up, or were you performing some kind of stress test at
the time?

I've put up a patch adapted to 2.1.108:

ftp://mozart.stat.wisc.edu/pub/misc/patch-2.1.108-freeinodes

I tested this patch against a vanilla 2.1.108 kernel, both with the
machine's "natural" 24 megs and with a "mem=10M" boot option to
simulate a low-memory machine. I stress-tested it as best I could,
and it seemed to work fine. Give it a try. If it still doesn't work,
we'll try to figure out why: maybe you use some unusual filesystem
configuration, like an NFS root partition or something?

Also, I've noticed that the default sysctl settings for my inode
freeing code are *way* too agressive for the default kernel swap
settings. This is because I've been using:

echo 10 80 90 > /proc/sys/vm/pagecache
echo 3 25 50 > /proc/sys/vm/buffermem

in my bootup scripts to relax "kswapd".

You'll either need to use swap settings like these or determine some
less aggressive "/proc/sys/fs/inode-cache" and "dentry-cache"
settings. Otherwise, your "inode" cache will be kept ridiculously
small (around 200 entries even on an unloaded 24 meg machine).

With the above settings, on a 24 Meg machine, the inode cache will
typically grow to around 8000 or 10000 entries when there is no other
memory pressure; on a 10 Meg machine it only grows to a couple
thousand. In either event, it is quickly pruned when the memory is
needed for something "important".

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