From owner-freebsd-threads@FreeBSD.ORG Wed Jul 5 05:20:36 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 5153916A4E0; Wed, 5 Jul 2006 05:20:36 +0000 (UTC) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5E9A43D55; Wed, 5 Jul 2006 05:20:34 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [192.168.2.4]) ([10.251.60.25]) by a50.ironport.com with ESMTP; 04 Jul 2006 22:20:35 -0700 Message-ID: <44AB4C22.3030109@elischer.org> Date: Tue, 04 Jul 2006 22:20:34 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kmacy@fsmware.com References: <20060703101554.Q26325@fledge.watson.org> <200607042204.52572.davidxu@freebsd.org> <44AAC47F.2040508@elischer.org> <200607041819.05510.peter@wemm.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-threads@freebsd.org, Daniel Eischen , Robert Watson , 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 05:20:36 -0000 Kip Macy wrote: > I believe that the views that Peter has expressed are held by quite a > few. I initially integrated bike_sched in my development branch for > the purpose of playing with different locking strategies. More > recently I've integrated it into my stable branch after discovering > that it greatly improved the stability of threaded applications. As a > consequence of it being in my stable branch it has been integrated > into a widely watched development project. I'll leave it to the > developer on that project to discuss it on -current. As someone who > has yet to make substantial contributions to FreeBSD it is not my > place to advocate for or against KSE. However, I will say, without > equivocation, that KSE needs a fair amount of TLC in the form of > re-factoring and bug fixes for it to have a place on future hardware. > > -Kip > > I wrote the threading code into the system with the aim of supporting as many threading models as I could. In this light, you will notice that 1:1 threads is fully supported. It was always imagined that as time went on, various models would fall by the wayside. The first arrow in the came when it was found that KSE for some of the newer architectures (alpha and ia64) would be far harder than expected due to the fact that thread state is not always stored where you would expect it to be. This happenned fairly early on and necessitated a change in course part way through. it never really recoverred from this. The code to store a blocking thread and jump to another (newly created) one was never able to be really optimised, but it worked (kinda). The big problems are that a lot of code assumes things that are just not true when some of the threads are not resident in the kernel and have no actual trace in the kernel at all. It would have been good to see an app that could use M:N affectively, and there is some indication that some Java VMs may come under this category as I have heard of java VMs with 10,000 threads of which most are not involved with I/O. However I have never seen any sign of such a beast with my own eyes. 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. I might add, as I did before that the double level scheduer with threads hanging off the KSEGRP until they can be run by the main scheduler when there are enough "opennings" for that process/ksegrp is orthogonal to this discussion and if that is all removed in Peter's skunkworks project then that is a separate issue that must be addressed under a different banner. Simplifying the scheduler by removing that just allows a process to overwhelm the scheduler with its own threads but it could be allowed to do that equally for both M:N and 1:1 threads., (Peter is this part of what you did?) >> > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to > "freebsd-threads-unsubscribe@freebsd.org"