Re: Proposed approach for malloc to deal with failing brk

[Rich Felker <dalias@aerifal.cx>]

On Tue, Apr 01, 2014 at 08:40:57PM +0400, Vasily Kulikov wrote:
> 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.

Commit accounting. Committing 100 megs to a process that's only asked
for (and only going to use) 100k is harmful because, in effect, it
forces people to turn on (or leave on) overcommit.

> > 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.

Well the page table changes happen even if you just use madvise to
zero/'free' the memory and then a page fault on write to get it back,
and the latter is very fast compared to the mprotect approach, at
least as far as I can tell. So I think the VMA split/merge is the big
issue.

Rich