Date: Fri, 24 Mar 2006 14:42:25 -0800 From: Jason Evans <jasone@FreeBSD.org> To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no> Cc: cvs-all@FreeBSD.org, cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Julian Elischer <julian@elischer.org>, Peter Wemm <peter@FreeBSD.org> Subject: Re: cvs commit: src/lib/libc/sys mmap.2 Message-ID: <442475D1.5010903@FreeBSD.org> In-Reply-To: <86k6ajpmvb.fsf@xps.des.no> References: <200603232337.k2NNb6tH020675@repoman.freebsd.org> <86irq45etp.fsf@xps.des.no> <442444C4.8020404@elischer.org> <86k6ajpmvb.fsf@xps.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Dag-Erling Smørgrav wrote: > Julian Elischer <julian@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?442475D1.5010903>