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.
Cheers,
~sparker
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Dec 07 2001 - 21:00:32 EST