Re: fork performance

On 18/10/2012, at 8:39 PM, Lars Heidieker <[email protected]> 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
>=20
> that's why the map entries for anon memory don't get merged.
>=20
> 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