More info: 2.1.108 page cache performance on low memory

Stephen C. Tweedie
1998-07-13T16:57:20Z

Hi all,

OK, a bit more benchmarking is showing bad problems with page ageing.
I've been running 2.1 with a big ramdisk and without, with page ageing
and without. The results for a simple compile job (make a few
dependency files then compile four .c files) look like this:

2.0.34, 6m ram: 1:22

2.1.108, 16m ram, 10m ramdisk:
With page cache ageing: Not usable (swap death during boot.)
Without cache ageing: 8:47

2.1.108, 6m ram:
With page cache ageing: 4:14
Without cache ageing: 3:22

So we can see that on these low memory configurations, the page cache
ageing is a definite performance loss. The situation with the ramdisk
is VERY markedly worse, which I think we can attribute to an
overly-large page cache due to the %age-physical-memory tuning
parameters; I'll be following this up to check (that's easy, since those
parameters are sysctl-able). This is not an artificial situation:
having the page cache limits fixed in terms of %age of physical pages is
just not going to work if you can have large numbers of those pages
locked down for particular purposes. Effectively we're reducing the
size of the page pool without the vm taking it into account.

Performance sucks overall compared to 2.0. That may well be due to the
extra memory lost to the inode and dirent caches on 2.1, which tend to
grow much more than they did before; it may be that we can address that
without too much pain. It is certainly possible to trim back the
kernel's ability to stop caching unused inodes/dirents, and although a
self-tuning system will be necessary in the long term, putting bounds on
these caches will at least let us see if this is where things are going
wrong.

I'll be experimenting a bit more to try to identify just where the
performance is disappearing here. However you look at it, things look
pretty grim on 2.1 right now on low memory machines.

--Stephen