RFC: replace ptmalloc2
Rich Felker
dalias@libc.org
Wed Oct 15 04:00:00 GMT 2014
On Tue, Oct 14, 2014 at 04:32:54PM -0700, Jörn Engel wrote:
> On Thu, Oct 09, 2014 at 10:02:29PM -0400, Rich Felker wrote:
> >
> > The sane behavior is to keep the same PROT_NONE/mprotect pattern, but
> > expand by exponentially increasing amounts rather than one page each
> > time. E.g. force the Nth expansion to be at least 2^N pages.
>
> Or maybe not mprotect at all and do some slow-start algorithm for mmap.
> There are many options one can pick from. Main question is how to keep
> the code as simple as possible while achieving the goal.
The exponential expansion approach I described is just a couple lines
of code and completely non-invasive. Yes there are other approaches
like multiple mmaps (so that you never need PROT_NONE) but they have
worse address space fragmentation properties.
> For the moment I just removed the mprotect completely for some
> benchmarks. That brings ptmalloc2 pretty close to jemalloc. In some
> microbenchmarks it is 30% slower, in some it is 30% faster. Both of
> them consistently outperform tcmalloc, which came as a surprise.
This is roughly what I expected.
> And jemalloc seems to have a nasty design flaw. It is essentially a
> buddy allocator once you cross a certain size. Size used to be 512B in
> 2006 and is 4k for the binary I tested. malloc(4097) will return 8k,
> causing up to 2x memory overhead. Improving this in jemalloc seems much
> harder than improving ptmalloc2, so my quest to replace the default
> allocator is over.
>
> Anyhow, here are some raw numbers for the curious. Benchmark allocated
> 2GB in 8 threads in sizes between 384B and 12288B and memset the memory.
> runtime VmRSS VmData maps syscalls
> libc 7.165s 2107908 2590048 67 332955
> libc-mprotect 0.768s 2107944 2399808 35 4149
> jemalloc 0.962s 2652152 2695332 42 5521
> tcmalloc 1.510s 2245760 2278460 47 38766
>
> In this particular benchmark my hacked-up ptmalloc2 is winning, while a
> standard ptmalloc2 is clearly the worst of the bunch.
What benchmark are you using? I'd like to run it on my malloc.
Rich
More information about the Libc-alpha
mailing list