Re: fork performance

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

On Thu, Oct 18, 2012 at 4:39 PM, Lars Heidieker <lars%heidieker.de@localhost> 
wrote:
> -----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().
>>
>> David
>>
>
> Hi,
>
> 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?