Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 10 Mar 2007 23:38:03 +0900
From:      LI Xin <delphij@delphij.net>
To:        freebsd-arch@freebsd.org
Cc:        MingyanGuo <guomingyan@gmail.com>
Subject:   locking reasoning within fork1()
Message-ID:  <45F2C2CB.5000204@delphij.net>

next in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7DC38480C3AE5AE641F6D7E0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

During the AsiaBSDCon DevSummit we have go through the current KSE and
some userland threading code, and I think that brings me back to the
fork1() vs others races.

The current logic, especially the locking order found in fork1() looks
not very ideal according to my read.  I have pursued some code from
other BSDs, and I think we might want to address the following problems:

 - At which point we should consider that a process really exists?  At
this point, there is no clear point that we can call a process as
"really born".  It looks to me that PRS_NEW just indicate that a process
is not "fully initialized", but it does not provide information about
"how much initialization did we done".  This would make several
operation very questionable, and is more error-prone.  As Guo (cc'ed)
pointed out, there are chances that kill(0, ..) and kill(-1, ..) would
not cover PRS_NEW processes, there might be also some other places where
should take care of.

 - The locking scheme does not look pretty.  We grab and release locks
again and again, and it might be more optimal to collapse some work
together, and re-consider synchornization with other parts of the kernel.=


 - Certain parts of struct proc is mostly not accessed frequently.  For
the sake of better exploit of cache, we may want to consider to move
certain parts out from the struct.

 - The PID allocation is somewhat expensive when there are a lot of
processes.  This might not be a very big deal, though, but given that it
requires to hold a sx_xlock, our scalability could be limited due to
this.  tjr@ has a proposed hash based PID allocation patch in his p4
branch, and NetBSD have an O(1) algorithm that may worth to have a look a=
t.

Cheers,
--=20
Xin LI <delphij@delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!


--------------enig7DC38480C3AE5AE641F6D7E0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF8sLLOfuToMruuMARCvCoAJ9qX9oF/NTbOghIKVybZUDb7o1vBACdFAWy
A4/WU6gKcnKJRIHWKPvL25w=
=d1Dj
-----END PGP SIGNATURE-----

--------------enig7DC38480C3AE5AE641F6D7E0--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45F2C2CB.5000204>