> Let's try this one... this has:
>
> 1) buffer cache clean buffer out of memory fixes
> 2) handle multi-page allocations in low memory situations
> (sans GFP_ATOMIC) more gracefully
> 3) Matthias's state machine fix
> 4) Debugging code added to try_to_free_page() for when it fails
>
> I ran a kernel compile in 3mb of ram on a Sparc (which makes the
> machine useless, _very_ useless) and as far as it got (I let it run
> for a day, I wasn't going to let it finish) it did not allow one
> try_to_free_page() to fail, not once.
Looks pretty good so far.. I am running a badblocks on a 2Gb disk, and
although some stuff did get swapped out, it is about normal and the
working set for the active processes stays in the core without problems.
The system is also responsive while I type this message, but from time to
time it has small hiccups of half a second or so.
I did get one of the debugging messages though:
Jun 13 05:09:40 moisil kernel: 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 is a fairly vanilla pre-2.0.31-2 kernel with your patch and Hubert's
patch applied. The disk being checked is SCSI, _and_ holds the main
swap partition. freepages settings are 128 256 512, 48Mb of memory.
I'll try again after it badblock finishes, this time with much lower
settings for freepages and with the swap partition on an IDE drive.
[minutes later]
Even with 96 128 144 in freepages and checking a totally unused (and fast)
drive it doesn't make much of a difference. No messages in the logs this
time.
[even more minutes lates]
Booting w/ mem=4MB (w/ mem=3MB it simply doesn't finish the boot process),
badblocks still works ok. Again, no messages.
Ionut
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.