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.
Larry
>Date: Mon, 16 Jun 1997 23:57:24 +0200
>From: "Dr. Werner Fink" <werner@suse.de>
>CC: groudier@club-internet.fr, davem@jenolan.rutgers.edu,
> linux-kernel@vger.rutgers.edu
>
>> 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