From owner-freebsd-threads@FreeBSD.ORG Mon Jul 10 09:04:39 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 E4FEB16A4E6 for ; Mon, 10 Jul 2006 09:04:38 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F09943D5A for ; Mon, 10 Jul 2006 09:04:36 +0000 (GMT) (envelope-from kip.macy@gmail.com) Received: by wr-out-0506.google.com with SMTP id 68so595018wri for ; Mon, 10 Jul 2006 02:04:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Jaqeb9FG3mN5cLA/6SuNn8gV/EOOJNOfgc5TU8PRD42LSMDaDBAedI4+FxXHnfU2o9kSBsQN3zb4QZkwWxYH0iGnMSMSJGCMfJrVh3GLn1c/D8AMUMffw17VyRgSIfQpqaYj7wNSV19rFEnk4tXKGHIrLaCK87nbmymH1puZuPU= Received: by 10.65.219.7 with SMTP id w7mr4370487qbq; Mon, 10 Jul 2006 02:04:30 -0700 (PDT) Received: by 10.65.225.9 with HTTP; Mon, 10 Jul 2006 02:04:30 -0700 (PDT) Message-ID: Date: Mon, 10 Jul 2006 02:04:30 -0700 From: "Kip Macy" To: "Robert Watson" In-Reply-To: <20060705095450.O64340@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060703101554.Q26325@fledge.watson.org> <200607042204.52572.davidxu@freebsd.org> <44AAC47F.2040508@elischer.org> <200607041819.05510.peter@wemm.org> <44AB4C22.3030109@elischer.org> <20060705095450.O64340@fledge.watson.org> Cc: freebsd-threads@freebsd.org, Daniel Eischen , David Xu , threads@freebsd.org, 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 Reply-To: kmacy@fsmware.com List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 09:04:39 -0000 Apart from real time scheduling functionality I have yet to see any real-world technical deficiencies with libthr. I have, however, seen major stability issues with KSE. Network Appliance abandoned FreeBSD as a platform for running their simulator due to frequent hangs caused by signals. More recently, on sun4v, when single stepping csup (or any multi-threaded app for that matter) the debuggee would often get the SIGTRAP and not GDB. When re-starting mysqld for the second or third time the process would become unkillable. These problems are not entirely surprising, KSE makes signal handling *very* complicated. I am disappointed that threads are currently unusable on sun4v with KSE. I would be delighted if sometime in the very near future, one of the following happened: 1. a) Somebody steps up to work on KSE and fixes the signal issues that have long plagued it. John Birrell or Paul Saab can make a T2000 available to any motivated developer. 2. a) David Xu fixes static linking with libthr b) David Xu exports support for real-time scheduling via libthr c) Peter Wemm checks in bike_sched The second seems much more logical, given our desire to become performance competitive with Linux. However, sched_lock is not currently FreeBSD's biggest bottleneck, and thus the first would be acceptable. I would still be pleased at the possibility of sun4v someday being checked into CVS. -Kip On 7/5/06, Robert Watson wrote: > > 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 >