I've been noticing some weird cache/swap behavior under 2.4.1 and
2.4.2. If there is a large amount of allocated cache space, a program
requests a lot of RAM, and then the program exits, then one can end up
using lots of swap while having a hefty cache, which doesn't make much
sense. Here is a sample run: ("allocram N" is a trivial program to
allocate and dirty N MB of RAM.)
# free
total used free shared buffers cached
Mem: 255564 49344 206220 0 420 5496
-/+ buffers/cache: 43428 212136
Swap: 163832 0 163832
# find / -type f|xargs cat > /dev/null
# free
total used free shared buffers cached
Mem: 255564 253248 2316 0 7764 189300
-/+ buffers/cache: 56184 199380
Swap: 163832 0 163832
# allocram 300 &
# free
total used free shared buffers cached
Mem: 255564 254004 1560 0 316 32764
-/+ buffers/cache: 220924 34640
Swap: 163832 130172 33660
# [1]+ Done allocram 300
# free
total used free shared buffers cached
Mem: 255564 65508 190056 0 400 39852
-/+ buffers/cache: 25256 230308
Swap: 163832 48444 115388
Why do I have 47MB of swap in use? I thought at first that it might
be due to the minimum allowable cache size, but considering that there
was only 48MB of RAM in use to begin with, that still seems
suspicious. Even weirder, if I then turn off swap, the usage looks
more reasonable:
# swapoff -a
# free
total used free shared buffers cached
Mem: 255564 53900 201664 0 840 9356
-/+ buffers/cache: 43704 211860
Swap: 0 0 0
This system is an Athlon T-bird 900 on a Asus A7V (KTX-133-based)
motherboard, if that matters. I don't have any other 2.4.x systems to
try it on. NB: X 4.0.1 with tdfx freezes for a few seconds during the
swapoff -a process, but it does recover.
- Morty
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
