[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: fork performance
On Thu, Oct 18, 2012 at 4:39 PM, Lars Heidieker <lars%heidieker.de@localhost>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On 10/18/2012 09:15 AM, David Laight wrote:
>> On Thu, Oct 18, 2012 at 12:52:47PM +1300, Lloyd Parkes wrote:
>>> So, with a slightly closer look, a guess and some tests to
>>> verify my guess, and I think I have found my performance problem
>>> converting the NetBSD CVS repositories to Mercurial.
>>> The CVS server forks once for each command it receives, and it
>>> receives a lot of commands. NetBSD fork(2) seems to be much
>>> slower than OS X fork(2).
>> I've seen things that show that a processes memory page list isn't
>> getting its entries merged - so there are a lot of items to
>> process during fork(). (cat something in /proc ...)
>> The malloc netbsd uses (that uses mmap() instead of sbrk())
>> probably makes this much more significant. Especially if a big C++
>> program - like a python interpreter - is doing the forks().
> 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.
What happens if larger page size is used?
Main Index |
Thread Index |