RFC: replace ptmalloc2

[Siddhesh Poyarekar]

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.

That will fragment the arenas, while mprotect'ing larger portions of a
mapped arena will result in lesser number of syscalls and avoid the
fragmentation too.  An initial simple patch might be to just use
TRIM_THRESHOLD as a guideline to call mprotect.  That ought to be a
big step forward from where we are now and will also get the non-main
arena expansion logic in line with the main arena expansion.

> In this particular benchmark my hacked-up ptmalloc2 is winning, while a
> standard ptmalloc2 is clearly the worst of the bunch.

This is not a surprise here because you just traded performance for a
larger memory footprint at the outset by getting rid of mprotect.

Siddhesh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20141104/5602fb85/attachment.sig>