cvs commit: src/lib/libc/sys mmap.2

[Jason Evans]

Dag-Erling Smørgrav wrote:
> Julian Elischer <julian at elischer.org> writes:
> 
>>Dag-Erling Smørgrav wrote:
>>
>>>Are you saying that mmap() is not constrained by maxdsiz?
>>
>>that seems to be the case from my experience.
> 
> 
> That's bad.  Our new malloc() uses mmap() to allocate arenas, which
> means that dsiz no longer has any effect.  I've just confirmed this:
> 
> # phkmalloc on 5.4 / i386
> % ulimit -d
> 524288
> % ./allocate
> 511
> 
> # jemalloc on 7.0 / i386
> % ulimit -d
> 524288
> % ./allocate
> 697
> 
> # jemalloc on 7.0 / amd64
> % ulimit -d
> 524288
> % ./allocate
> 1844^C
> 
> Note the discrepancy on 7.0 / i386 - it does stop, but only after
> exceeding dsiz by about 50%.  On amd64, it'll happily keep going until
> it hits vsiz, which is unlimited by default.

By choosing a malloc size of 1MB in your test program, you just happened 
to pick the worst possible case for malloc chunk fragmentation (50% 
utilization).  In reality, the reason that you hit a limit of 697 on 
i386 is that you used pretty much the entire mmap()able address space 
(2*697MB == 1394MB).  On i386, jemalloc switches from sbrk() to mmap() 
when heap space runs out.

Jason