From owner-freebsd-threads@FreeBSD.ORG Mon Jul 3 09:30:07 2006 Return-Path: X-Original-To: threads@FreeBSD.org Delivered-To: freebsd-threads@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA65116A407 for ; Mon, 3 Jul 2006 09:30:07 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5605443D45 for ; Mon, 3 Jul 2006 09:30:07 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id DE26D46C8F for ; Mon, 3 Jul 2006 05:30:06 -0400 (EDT) Date: Mon, 3 Jul 2006 10:30:06 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: threads@FreeBSD.org Message-ID: <20060703101554.Q26325@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Strawman proposal: making libthr default thread implementation? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2006 09:30:07 -0000 I know this has been discussed in the past, but I figured with 7.x trundling forward, it was time to think about it again. In benchmarks for many common applications and scenarios, libthr demonstrates significantly better performance over libpthread -- this is not a coincidence, as David Xu has invested a lot of time in improving libthr and application performance, and libthr has benefitted significantly from the last ten years of threading work on FreeBSD. libthr is also implemented across a larger number of our platforms, and is already libpthread on several. The first recommendation we make to MySQL and other heavy thread users is "Switch to libthr", which is suggestive, also! Likewise, I know David has worked hard to eliminate technical and standards obstacles that have been raised in the past. This e-mail is a strawman proposal, intended to raise discussion, and possibly lead to action. So the strawman proposal is: make libthr the default threading library on 7.x. A few questions given the proposal: - Are there technical features present in libpthread that aren't yet in libthr, and are required? In the past system/local thread support has been the complaint, but I believe that is now long fixed. This is useful regardless of a switch. - A further thought: it would be really nice to be able to benchmark the behavior of applications like Mozilla, Tor, KDE, etc, which also depend on threads, but which don't come with easy-to-use potted benchmarks (that I know of). Can we get some hands to help explore this issue? This is also useful regardless of a switch. - What mechanism should be used? Should libthr simply be compiled as libpthread, and libpthread as libkse, so that they can both be around and libkse can be used for benchmarking still? - Are there significant objections to doing this? BTW, the one technical concern I have with libthr is that under high contention kernel activity involving a small number of kernel locks, libkse implicitly reduces kernel lock contention by bounding the number of threads that can be in the run state in the kernel. If, for example, you have 32 threads, all performing accept() and then file descriptor I/O in a tight loop, libpthread will often perform significantly better, as libthr allows them all into the kernel at once. This is most likely a scheduler issue, but it's significantly mitigated by M:N threading. To experiment with this problem, which I may not have characterized, you can try out the src/tools/tools/netrate/{http,httpd} micro-benchmarks using the -t argument to force threaded instead of process-based behavior. This effect seems not to come out as a practical issue in macro-benchmarks I've tried, perhaps as they are generally tuned for Linux threading, which presumably faces the same problem as our 1:1 package. Exploring this issue is a strong argument to continue to support multiple thread libraries in the development branch, as you can't do a comparative evaluation if you don't have choices to compare! If we're going to think about this seriously for 7.0, increasing libthr exposure sooner rather than later is probably a good idea. Robert N M Watson Computer Laboratory University of Cambridge