Re: fork performance

[Lloyd Parkes <lloyd%must-have-coffee.gen.nz@localhost>]

On 18/10/2012, at 8:39 PM, Lars Heidieker <lars%heidieker.de@localhost> wrote:

> currently the amap layer limits the size of amaps to 255 * PAGE_SIZE
> see: http://nxr.netbsd.org/xref/src/sys/uvm/uvm_amap.c#494
> 
> that's why the map entries for anon memory don't get merged.
> 
> This will hit fork performance.

I've just had another look at the ktrace data and this could be what's causing 
the problem for CVS. The CVS server is calling mmap quite a lot for anonymous 
memory. CVS doesn't appear to call mmap directly, but jemalloc shouldn't be 
mapping memory in chunks as small as what I'm seeing. I'm just going to have to 
poke it with a stick and see what happens.

I also decided to swallow my BSD pride and try running this code on Linux. It 
turns out that Linux is nowhere near as fast as OS X either, so maybe I 
shouldn't feel too bad.

Thanks for the advice.

Lloyd