[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: fork performance
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.
Main Index |
Thread Index |