Swap crash with pre-2.0.31

Rauli Ruohonen (raulir@fishy.pp.sci.fi)
Fri, 30 May 1997 22:19:56 +0300 (EET DST)

I was testing what named would do if I send random binary data to it, and
it began eating memory (slowly). When its size was a little bit above 4 MB
(this is 20MB machine), the kernel started hitting the disk (not heavily).
Nothing else happened, only things I could do was listen to the disk and
type commands (but programs were never scheduled - no response). And I
had a real-time shell running, so it's not a case of a program fork():ing
or something, I believe the kernel had entered a long loop and thus
nothing else ran.

When I used SHIFT-ScrollLock to see whether anything was swapping,
everything was OK (normal, as before), but there still was something
peculiar: The line "Swap cache: add 360/360, delete 220207/286, find 3940/2"
numbers were constantly going up, as all other numbers varied only a little
(not to a specific direction, they "wiggled" up and down).
This was the last line I saw, as I hit the reset button:

Swap cache: add 4085/4085, delete 294359/1738, find 12093/2338

The "add" values were still increasing rapidly.

This kernel is pre-2.0.31 with all fixes and no other patches (such as
memory reserve patch). The machine is 486DX2, and hasn't had any problems
of this type before, actually this DNS test was the only thing I have
ever seen to trigger this - uptime was 11 days, and during that the
machine was sometimes heavily swapping, and always doing something.

fishy:/home/raulir>free
total used free shared buffers cached
Mem: 18712 18368 344 11804 856 7192
-/+ buffers: 10320 8392
Swap: 31184 6176 25008

/etc/fstab swap lines:

/dev/hdb1 none swap sw
/dev/hda2 none swap sw,priority 3

Btw, what do these mean (came with ~1.5 MB swapping, normal usage):

try_to_free_page: state(2) stop(1847308) i(0) sleep instead of fail
try_to_free_page: state(1) stop(1847308) i(0) sleep instead of fail
try_to_free_page: state(2) stop(1847308) i(0) sleep instead of fail

I know they're debugging messages, but.. (yes, they are correct values, I
have that David's printk() fixed :))