Re: vmscan.c heuristic adjustment for smaller systems

From: Marc Singer
Date: Sat Apr 17 2004 - 16:34:27 EST


On Sat, Apr 17, 2004 at 12:38:55PM -0700, William Lee Irwin III wrote:
> Marc Singer reported an issue where an embedded ARM system performed
> poorly due to page replacement potentially prematurely replacing
> mapped memory where there was very little mapped pagecache in use to
> begin with.
>
> Marc Singer has results where this is an improvement, and hopefully can
> clarify as-needed. Help determining whether this policy change is an
> improvement for a broader variety of systems would be appreciated.

I have some numbers to clarify the 'improvement'.

Setup:
ARM922 CPU, 200MHz, 32MiB RAM
NFS mounted rootfs, tcp, hard, v3, 4K blocks
Test application copies 41MiB file and prints the elapsed time

The two scenarios differ only in the setting of /proc/sys/vm/swappiness.

swappiness
60 (default) 0
------------ --------
elapsed time(s) 52.48 52.9
53.13 52.91
53.13 52.87
52.53 53.03
52.35 53.02

mean 52.72 52.94

I'd say that there is no statistically significant difference between
these sets of times. However, after I've run the test program, I run
the command "ls -l /proc"

swappiness
60 (default) 0
------------ --------
elapsed time(s) 18 1
30 1
33 1

This is the problem. Once RAM fills with IO buffers, the kernel's
tendency to evict mapped pages ruins interactive performance.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/