So here is some kind of report about my investigation...
First of all - a little bit about my system. It is PII-350,
256M RAM, one 9G SCSI disk (hosted by Adaptec) and one 1.7G IDE.
Other hardware parts are irrelevant (I hope), at least nothing special.
Kernel - 2.3.99-pre6-5 (as is), Slackware 7.0 (libc6).
Problem: heavy swapping on almost not loaded system (only X with
Netscape and few compilations; nearly no network activity except
of slow dialup link).
After one day run I've found that swap size is about 40M, it never
was so big on 2.2.*, and even in 2.3.40+.
The Experiment:
- boot fresh;
- turn off swap;
- start X and several times xterm and Netscape (as usual);
Then:
$ find / -xdev -type f | xargs -n 1 -P 100 md5sum
(in short, if you don't want to look in TFM - very good
stress test - spawn up to 100 copies of md5sum with only
one file as argument, this way process all the files found).
My root system resides on IDE disk, for curious:
$ df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda2 999936 717212 232728 76% /
So it is about 700M of stuff.
Memory usage right before starting 'find' was pretty low -
about 6M for buffers and 20M of cache, with free ~150M.
After long run of command above (and in process of):
$ free
total used free shared buffers cached
Mem: 254456 251232 3224 0 4876 174016
-/+ buffers/cache: 72340 182116
Swap: 0 0 0
Buffer memory (sure) fluctuated (4-12M (!!)), cache grows (only). When
amount of free memory reached ~4M, system become _extremely_ slow
(but functional).
Then I tried to replace md5sum with "cat >/dev/null" - same effect -
buffer usage was still very low (up to 6M). In past, I used to see
that buffers tend to eat all unused memory, but now I see that cache
has priority...
Then... Final part:
$ cat /dev/sda3 >/dev/null
Buffers are filled in, cache shrinks. Then I tried find with cat again
(remember - buffers were filled in from different device), and... Buffers
shrinks (to ~6M), cache grows... Seems that file operations are
different from raw device I/O - in first case cache has priority, in second
- buffers.
So, memory managemnt in -pre series is (at least) terrible, especially
if you have swap (with swap turned on system was even more slow).
That's all. No conclusions - just facts. Manipulations of /proc/net/vm
had no effect.
May be someone who is very familiar with this part of the kernel can explain
what is going on? :))
NB: Please be very careful if you plan to reproduce my "stress test" on -pre
series - it can hang your system :)
Good luck!
/Al
-
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.tux.org/lkml/