> Problem is that libc malloc() appears to use brk() only, so
modern libc's certainly use mmap for large mallocs. but this can be a
serious problem: I corresponded with someone who had a binary app that
did many small mallocs, and he was pissed that his 4G box could only malloc
900M or so. this happened because __PAGE_OFFSET and TASK_SIZE were 3G,
but TASK_UNMAPPED_BASE, where mmap's start, is TASK_SIZE/3.
a hackish solution that worked was TASK_UNMAPPED_BASE=TASK_SIZE-0x20000000,
which just assumes that you won't need >512M of mmaped areas.
since the heap grows up and the stack is generally small and limited,
it would be nice to arrange for mmaped areas to grow down.
as far as I can tell, we could just sort vmlist in descending order.
would there be some problem with doing this?
regards, mark hahn.
-
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/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:12 EST