Re: [patch] Make the mmap/brk threshold in malloc dynamic to improve performance

[Arjan van de Ven <arjan at linux dot intel dot com>]

Steve Munroe wrote:
>  > 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.

however, in modern Linux, TASK_UNMAPPED_BASE no longer exists.
(and this includes enterprise distributions such as RHEL3, but for sure 
anything with 2.6.9 kernels and later). So while this argument holds for 
old linux from more than a year ago, it no longer holds today
>  > * 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.

brk is demand page-faulted just as mmap is though... so I don't see a 
problem

>  > * 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.

especially tlb reach and pagetable memory use ;)