strange VM and swap behavior ?

Marc Lefranc (Marc.Lefranc@nordnet.fr)
29 Aug 1999 15:16:59 +0200


Summary: I observe strange behavior related to virtual memory and
swap. When playing an animated gif with xanim, virtual memory can
eventually be exhausted although the total of physical memory + swap
is well above what should be needed. Also, the amount of "cached"
memory is strangely high for a situation of heavy swapping, and there
seems to be some duplication between swap and the cached pages. VM
exhaustion seems to depend sensitively on timings.

Configuration: RedHat 5.2 with 2.2 updates on a P5 233 MMX, vanilla 2.2.12
kernel.
Physical Memory available = 96012 K,
1 swap partition of 50396 K, 1 swap file of 51196 K, hence
total swap=101592 K,
total VM=96012+101592=197604 K

What free(1) reports right after booting and login (X+kdm+WindowMaker+3 xterms
running)

total used free shared buffers cached
Mem: 96012 29992 66020 22848 1224 17236
-/+ buffers/cache: 11532 84480
Swap: 101592 0 101592

So it seems that ~ 12 Mb suffice to handle the processes running so far.

I then launch xanim to play a animated gif. The animation consists of
256 400x400 images. The xanim grows to a stable size of ~ 109000 K :

lefranc 354 3.2 61.3 109536 58920 p2 D 11:47 0:18 xanim triang2.gif

Of course, the machine is heavily swapping, but it remains quite
usable (impressively). What is surprising, however, is that much more
swap than expected is used. After a while, memory configuration is
typically stable at:

total used free shared buffers cached
Mem: 96012 93356 2656 11032 1360 64160
-/+ buffers/cache: 27836 68176
Swap: 101592 91860 9732

What is strange is that 93356+91860K are used which is much more than
the 109536+11532 than I would have expected. Notice the "cached"
figure of 64160 K. I would have expected that during heavy swapping,
this figure goes to zero.

We can now discuss the influence of timing. If I increase the playback
speed of xanim (by simply hitting the - key), swap space is quickly
exhausted: here is what free reports after a few seconds:

total used free shared buffers cached
Mem: 96012 94872 1140 18348 1376 75224
-/+ buffers/cache: 18272 77740
Swap: 101592 101592 0

Notice that the increase in the use of swap space is accompanied by an
increase in the "cached" figure. Notice also that
94872(used)+101592(swap)-75224(cached)=121240 K, which is extremely
close to the expected figure for memory occupied by processes. It
seems that an amount of swap roughly equal to the "cached figure" is
wasted.

This is confirmed by the following observation: Immediately after I
kill xanim (we should be back to the initial situation), free reports:

total used free shared buffers cached
Mem: 96012 70820 25192 4168 1376 63920
-/+ buffers/cache: 5524 90488
Swap: 101592 64748 36844

There should be ~ 12 Mb of running processes and there are 64748 K in
swap ! The high figure for cached is odd too.

Now, I swapoff the two swap areas, and here is the last output of
free:

total used free shared buffers cached
Mem: 96012 18144 77868 4480 1376 4564
-/+ buffers/cache: 12204 83808
Swap: 0 0 0

used -/+ buffers/cache is back to a normal value, and is only 6M above
the previous value. However, the "cached" and "swap used" figures have
dramatically decreased. It really looks (at least for a non-expert as
me) as if most of the swap space was used by cached pages, which is
quite odd for cached pages ? It is as if cached pages were not simply
thrown, but transferred into the swap space instead thereby wasting
valuable virtual memory.

This is not a memory leak, because when the cached pages are later
thrown, associated swap space is then freed, but this behavior
actually requires much more swap than would be strictly needed.

Thank you very much for any comment to enlighten me. I can do
additional tests if needed.

P.S. I have also tried which kernels compiled with -O3 -march=pentium
(this is with egcs 1.1.2), and with the -fno-strength-reduce flag
removed. The swap space is more rapidly exhausted, but this may be
simply due to a difference in timing, since I then get the same effect
as when increasing playback speed.

Marc.

-
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/