This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
> The real question Arjan and I have is what are the conditions under > which allocating using mmap is a win? Here's what I can think of: > > * When we're running out of brk() space - when does this happen?
We run into trouble when brk runs into TASK_UNMAPPED_BASE. This is normally where libraries, tls, and thread stacks get allocated. TASK_UNMAPPED_BASE is usually set to 1/4th or 1/3th of the address space. The trade-off is between brk storage and thread stack space.
> * When we don't ever touch most of the allocated memory
One can imagine very sparse arrays where virtual size is larger then real mem.
> * When it will reduce fragmentation in the brk()'d memory
There is a fragmentation problem when allocations tend to be a within 1 order of magnitude of the heap size.
Larger address spaces simplify the programming problems but there are still advantages to maintaining compact ranges within the address space. Linux does not seem to handle extremely spare address spaces well.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |