From owner-freebsd-threads@FreeBSD.ORG Wed Jul 5 08:54:21 2006 Return-Path: X-Original-To: freebsd-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 E4B0616A4DF; Wed, 5 Jul 2006 08:54:21 +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 426B843D55; Wed, 5 Jul 2006 08:54:21 +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 B727046C9D; Wed, 5 Jul 2006 04:54:20 -0400 (EDT) Date: Wed, 5 Jul 2006 09:54:20 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Peter Wemm In-Reply-To: <20060705092048.P70011@fledge.watson.org> Message-ID: <20060705095144.S64340@fledge.watson.org> References: <20060703101554.Q26325@fledge.watson.org> <200607042204.52572.davidxu@freebsd.org> <44AAC47F.2040508@elischer.org> <200607041819.05510.peter@wemm.org> <20060705092048.P70011@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Daniel Eischen , threads@freebsd.org, freebsd-threads@freebsd.org, David Xu , Julian Elischer Subject: Re: 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: Wed, 05 Jul 2006 08:54:22 -0000 On Wed, 5 Jul 2006, Robert Watson wrote: > management of kernel load. This advantage does not carry over to real-world > application loads, however, which tend to use a smaller thread worker pools > with sequences of locality-rich transaction, which is why libthr performs > btter as the workload approaches real-world conditions. This > micro-benchmark makes for quite an interesting study piece, as you can > easily vary the thread/proc model, the number of workers, and the > transaction size, giving pretty clear performance curves to compare. BTW, it would be really helpful if we had more (and perhaps better) potted benchmarks for threaded applications. Supersmack has made benchmarking MySQL easy, even though it turns out to be a rather un-representative workload (better workloads actually appear to shed better light on FreeBSD performance, FWIW). What I'm utterly unable to benchmark now are threaded UI applications, such as Mozilla, KDE, etc, which use threads quite a bit, but don't come with ways to capture their performance behavior reproduceably. I would really like to see a tool for measuring the perceivable latency impact of kernel changes on user applications. "It feels more snappy" is valuable but entirely anecdotal... Robert N M Watson Computer Laboratory University of Cambridge