From owner-freebsd-threads@FreeBSD.ORG Wed Jul 5 09:02:40 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 AA9DA16A4E2; Wed, 5 Jul 2006 09:02:40 +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 32BD743D58; Wed, 5 Jul 2006 09:02:40 +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 2DC7D46C82; Wed, 5 Jul 2006 05:02:39 -0400 (EDT) Date: Wed, 5 Jul 2006 10:02:39 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <44AB4C22.3030109@elischer.org> Message-ID: <20060705095450.O64340@fledge.watson.org> References: <20060703101554.Q26325@fledge.watson.org> <200607042204.52572.davidxu@freebsd.org> <44AAC47F.2040508@elischer.org> <200607041819.05510.peter@wemm.org> <44AB4C22.3030109@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-threads@freebsd.org, Daniel Eischen , kmacy@fsmware.com, David Xu , threads@freebsd.org 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 09:02:40 -0000 On Tue, 4 Jul 2006, Julian Elischer wrote: > If it come to pass that M:N threads are judged to be "unsuitable" then that > is a decision that I can live with, but never be let it be said that I > walled FreeBSD in to only having the option of 1:1 threads. Given that I have serious hindsight accuracy problems, I won't even talk about my foresight issues. :-) I think we shouldn't nail the KSE coffin closed just yet -- as Peter has already said, it's one thing to do a skunkworks hack of what might eventually be used, but it's quite another to show that the perceived benefit maps into real world benefit. I'd like to see that clearly shown before we do anything drastic. In particular, we need to show that the benefit is there for more than just a few poorly written benchmarks, but also for a range of real-world workloads, and that the scheduler simplifications pay off in terms of both code complexity and our ability to optimize. I also want to make sure we understand some of the artifacts better: the benefit of reducing per-process lock contention is significant, and I'm interested in understanding where on the workload spectrum the benefits of 1:1 outweight the benefits of M:N a bit better. Is my interpretation that this is M:N providing better kernel workload management correct, or is it an artifact of scheduler behavior? And, where future hardware and application trends will push workload behavior with respect to the optimizations we already have, not to mention the ones we are considering. Robert N M Watson Computer Laboratory University of Cambridge