Hi,

I'm interested in comments and feedback on this patch.


Attached below is "memstride.c", a simple program to exercise a process which
wishes to grow to the largest size of available VM the system can handle,
scribble in it all.  Actually, scribble in it all several times.

Under at least 2.4.14 -> 2.4.16, the VM system *always* over-commits to
memstride, even on an otherwise idle system, and ends up killing it.
This is wrong.  It should be possible for memstride to be told when
it has over-stepped the size of the system's total VM resources, by
having sbrk() return -1 (out of memory).


Also attached is my proposed fix for this problem.  It has the following
changes:

1.  Do a better job estimating how much VM is available
         vm_enough_memory() was changed to take the sum of all free RAM
         and all free swap, subtract up to 1/8th of physical RAM (but not
         more than 16MB) as a reserve for system buffers to prevent deadlock,
         and compare this to the request.  If the VM request is <= the
         available free stuff, then we're set.

2.  Be willing to sleep for memory chunks larger than 8 pages.
         __alloc_pages had an uncommented piece of code, that I couldn't
         see any reason to have.  It doesn't matter how big the piece of
         memory is--if we're low, and it's a sleepable request, we should
         sleep.  Now it does.  (Can anyone explain to me why this coded was
         added originally??)

The combination of these two changes makes it so that memstride passes.
Although memstride is a contrived example, it was contrived to parallel
behavior that was seen in many situations, with many different real
processes in normal use.  This fix allows those uncontrived programs
to run reliably.