I've encountered this problem too, but with the additional restriction of
having an environment with 8MB of RAM and no swap. I'm not sure I agree
with the ability to allocate more memory than you have available. So long
as each individual allocation is less than total memory, it seems to
succeed. When you get round to using it... it's not there of course, and
you get a SIGBUS or blocking. Sometimes it does nicely return ENOMEM and
malloc() gracefully returns - but most of the time it's a SIGBUS.
Looking at vm_enough_memory() (mm/mmap.c) it looks like only accessed
pages are counted against the amount of free memory (free + buffer +
cache + swap). A 'fix' would perhaps be to have a count of how many pages
are unpaged but allocated.
As another note: locked mmaps of files also seem to be counted towards
this figure - but locked pages can't be paged (SIGBUS - can't handle
kernel paging request when enough memory appears to be free). Locked mmaps
are also paged in on allocation even if they're not read/write (glibc
allocates 2MB at a time for thread heaps to get 1MB vm alignment - with 8MB
of RAM this means leaving a lot of spare floating about).
-- John Ripley, empeg Ltd. http://www.empeg.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/