Re: pre-2.0.32-2 + this patch works for me

Larry M. Augustin (
Tue, 17 Jun 1997 16:04:09 -0700

To recap, Gerard's latest patch worked well for me under a variety of
stress tests.

David's patch generated

try_to_free_page(3,0,0): FAIL try(shrink_mmap:shm_swap:swap_out) state[o(1):n(1)] stop[o(3):n(3)]

warning messages at the tail of the boot process, when most daemons
were just finishing initialization. This was on a 4MB RAM system. As
Werner says (below), this is a call to try_to_free_page by kswapd. I
wasn't doing any special stress testing to generate this. The normal
process of starting daemons at boot was enough.

I was also able to generate "couldn't get a free page" warnings (calls
to try_to_free_page in kmalloc) and the corresponding warning messages
from try_to_free_page (which I unfortunately don't have handy at the
moment) by stressing the system. Stress testing for me is
simulataneously running kernel compiles, bonnie, iozone, big
gzip/unzip jobs, etc.


>Date: Mon, 16 Jun 1997 23:57:24 +0200
>From: "Dr. Werner Fink" <>
>> This patch worked well for me. With it I was able to mke2fs a 45GB
>> raid partition on a system running with 4MB of RAM. Also, I was able
>> to run iozone and bonnie simultaneously with a kernel compile; no seg
>> faults, no "couldn't get a free page" reports from kmalloc.
>> Running davem's previous patch I was able to get try_to_free_page to
>> fail. The debugging output from try_to_free_page was (from memory):
>> try_to_free_page(3,0,0): FAIL try(shrink_mmap:shm_swap:swap_out) state[o(1):n(1)] stop[o(3):n(3)]
>This line is triggerd by kswapd ... because it will call try_to_free_page
>in mm/vmscan.c with wait == 0 (the last 0 in try_to_free_page(3,0,0)).
>On a "couldn't get a free page" you would see something like
>try_to_free_page(X,Y,1). Do you have run some stress test like
> while true; do make clean ; make -j zImage ; done
>in a kernel tree?
> Werner