Re: Proposed approach for malloc to deal with failing brk

[Vasily Kulikov <segoon@openwall.com>]

On Sun, Mar 30, 2014 at 20:41 -0400, Rich Felker wrote:
> We want brk. This is not because "brk is faster than mmap", but
> because it takes a lot of work to replicate what brk does using mmap,
> and there's no hope of making a complex dance of multiple syscalls
> equally efficient. My best idea for emulating brk was to mmap a huge
> PROT_NONE region and gradually mprotect it to PROT_READ|PROT_WRITE,

What problem do you try to solve via PROT_NONE -> PROT_WRITE?  Why not
simply instantly mmap it as PROT_WRITE?  Linux will not allocate physical pages
until the first access, so you don't lose physical memory when it is not
actually used.

> but it turns out this is what glibc does for per-thread arenas and
> it's really slow, probably because it involves splitting one VMA and
> merging into another.

Yes, both VMA split/merge and PTE/etc. changes.

-- 
Vasily