Re: fork performance

[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().
> 
> 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.

This will hit fork performance.

Lars

- -- 
- ------------------------------------

Mystische Erklärungen:
Die mystischen Erklärungen gelten für tief;
die Wahrheit ist, dass sie noch nicht einmal oberflächlich sind.

   -- Friedrich Nietzsche
   [ Die Fröhliche Wissenschaft Buch 3, 126 ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlB/sjgACgkQcxuYqjT7GRYU2QCgg4f8Vdjd7M+rboFRskmJtADc
mi8An1yODChGUoqyBu+qZjpWoinQohgf
=MmIm
-----END PGP SIGNATURE-----