Re: fork performance

-----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.
>>=20
>> 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).
>=20
> I've seen things that show that a processes memory page list isn't=20
> getting its entries merged - so there are a lot of items to
> process during fork().  (cat something in /proc ...)
>=20
> 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().
>=20
> David
>=20

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

- --=20
- ------------------------------------

Mystische Erkl=E4rungen:
Die mystischen Erkl=E4rungen gelten f=FCr tief;
die Wahrheit ist, dass sie noch nicht einmal oberfl=E4chlich sind.

   -- Friedrich Nietzsche
   [ Die Fr=F6hliche 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
=3DMmIm
-----END PGP SIGNATURE-----