From owner-freebsd-sparc64@FreeBSD.ORG Thu Apr 20 22:02:38 2006 Return-Path: X-Original-To: freebsd-sparc64@freebsd.org Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5501016A404 for ; Thu, 20 Apr 2006 22:02:38 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD4ED43D45 for ; Thu, 20 Apr 2006 22:02:37 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 95D961A4D9B; Thu, 20 Apr 2006 15:02:37 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id CD2F55509E; Thu, 20 Apr 2006 18:01:58 -0400 (EDT) Date: Thu, 20 Apr 2006 18:01:58 -0400 From: Kris Kennaway To: Miles Nordin Message-ID: <20060420220158.GA30820@xor.obsecurity.org> References: <20060420074713.Y52948@hades.admin.frm2> <20060420182331.GA26174@xor.obsecurity.org> <20060420204114.GA29490@xor.obsecurity.org> <20060420205340.GA29736@xor.obsecurity.org> <20060420210620.GA29933@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-sparc64@freebsd.org Subject: Re: pthread_mutex_timedlock on sparc64 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2006 22:02:38 -0000 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 20, 2006 at 05:52:19PM -0400, Miles Nordin wrote: > >>>>> "kk" =3D=3D Kris Kennaway writes: >=20 > kk> In practise libthr is the fastest thread package, although > kk> there must still be some reason we don't make it the default. >=20 > thanks for the answers. makes sense, I think I've finally got it. >=20 > For those forced to read all my noise today that haven't already heard > this 1:1 vs MxN thing debated to death, this is the last thing I read > about it: >=20 > http://www.sun.com/software/whitepapers/solaris9/multithread.pdf >=20 > ``This is not to say that a good implementation of MxN model is > impossible, but simply that a good 1:1 implementation is probably > sufficient. This paper does not attempt a discussion of the > relative merits of the MxN and 1:1 threading models. The basic > thesis is that the quality of an implementation is often more > important.'' >=20 > The context is, a bunch of papers were published since 1993 showing > that MxN threads were the most performant, and FreeBSD kse, Solaris > threads between 2.6 and 2.8, threads in OSF/1 (I think the kse guys > cited some Digital paper?), and NetBSD Scheduler Activations are all > based on the design in the original paper cited at the end of kse(2). >=20 > Sun scrapped scheduler activations in Solaris 2.9. They had to write > the above advertisement PDF to convince people who'd read all that > research since '93 that the 1:1 threads really were performant, and > that they didn't just wuss out after too many bugs and revert to a > slow, obvious EnTee/Linux style thread subsystem. As I said previously, the 1:1 implementation in FreeBSD is also usually faster (often much faster) than M:N. AFAIK, this is partly due to the unavoidability (at least on architectures like x86) of doing a syscall on thread context switch to save TLS state (this was not addressed in the SA papers), which is what a scheduler activations-like design was supposed to avoid. Kris --CE+1k2dSO48ffgeK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (FreeBSD) iD8DBQFESATVWry0BWjoQKURArlmAKDC2KRADNAR2HVoL09DiS1k+awrtgCg+1vH ZN0dmRTiDLs+SFp1ny98GoM= =W6d9 -----END PGP SIGNATURE----- --CE+1k2dSO48ffgeK--