Before & After Under The Giant Lock

[Kris Kennaway]

gregoryd.freebsd at free.fr wrote:
> Hello,
> 
> Quoting Robert Watson <rwatson at 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