From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 26 10:32:12 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED10C16A41B; Mon, 26 Nov 2007 10:32:12 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (pointyhat.freebsd.org [IPv6:2001:4f8:fff6::2b]) by mx1.freebsd.org (Postfix) with ESMTP id 18F0313C4EC; Mon, 26 Nov 2007 10:32:11 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <474AA0B4.8060107@FreeBSD.org> Date: Mon, 26 Nov 2007 11:32:20 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: gregoryd.freebsd@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> In-Reply-To: <1196069243.474a917b04d95@imp.free.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Robert Watson Subject: Re: Before & After Under The Giant Lock X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2007 10:32:13 -0000 gregoryd.freebsd@free.fr wrote: > Hello, > > Quoting Robert Watson : > >> 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