Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Nov 2007 11:32:20 +0100
From:      Kris Kennaway <kris@FreeBSD.org>
To:        gregoryd.freebsd@free.fr
Cc:        freebsd-hackers@freebsd.org, Robert Watson <rwatson@FreeBSD.org>
Subject:   Re: Before & After Under The Giant Lock
Message-ID:  <474AA0B4.8060107@FreeBSD.org>
In-Reply-To: <1196069243.474a917b04d95@imp.free.fr>
References:  <474830F9.90305@zirakzigil.org>	<6eb82e0711240638g2cc1e54o1fb1321cafe8ff9f@mail.gmail.com>	<1188.202.127.99.4.1195957922.squirrel@webmail.triplegate.net.id>	<20071125110116.U63238@fledge.watson.org>	<7bc80d500711251205w1a74b649mc3bd374545c1012c@mail.gmail.com>	<7bc80d500711251209p3bd78bc0leb37d4cb85f677f3@mail.gmail.com>	<20071125203321.G65286@fledge.watson.org> <1196069243.474a917b04d95@imp.free.fr>

next in thread | previous in thread | raw e-mail | index | archive | help
gregoryd.freebsd@free.fr wrote:
> Hello,
> 
> Quoting Robert Watson <rwatson@FreeBSD.org>:
> 
>> No problem -- just to be clear: in 7, users can still choose between
>> libpthread (m:n) and libthr (1:1), but the default is now libthr rather than
>> libpthread, as libthr seemed to perform better in most if not all workloads
>> of
>> interest.
> 
> I thought 1:1 would perform better with I/O bound processes running several
> threads.
> But wouldn't a process rely on a few I/O threads for several other CPU bound
> threads ? (unless specific activities such as a web server, or a database, which
> would explain MySQL performing better with 1:1)
> 
> Or, to make my point (somewhat) clearer: how did you actually compare advantages
> of 1:1 versus M:N when the change from the latter to the former was decided ?

We took a look at performance of the 1:1 implementation compared to M:N 
and noticed that the latter was completely terrible.  As in: slower and 
less scalable by 2 orders of magnitude -- on every workload we could 
find (except for one highly contrived microbenchmark).  M:N was a nice 
idea and maybe it could have been improved with a lot of work, but in 
practise no-one was able to make performance not suck.

> And second question: would it be possible to dynamically choose one way over the
> other: meaning if you know you're mostly I/O bound, then request for the 1:1
> type of threads, and vice versa ?

If you really really really (really) want to use the M:N libkse, you can 
use libmap to control it per-binary.

Kris



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?474AA0B4.8060107>