Dag-Erling Smørgrav wrote:
Julian Elischer <[EMAIL PROTECTED]> 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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
