From owner-freebsd-stable@FreeBSD.ORG Tue Nov 1 15:29:57 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EED2A16A41F for ; Tue, 1 Nov 2005 15:29:57 +0000 (GMT) (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 906E443D45 for ; Tue, 1 Nov 2005 15:29:57 +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 535A046B91; Tue, 1 Nov 2005 10:29:56 -0500 (EST) Date: Tue, 1 Nov 2005 15:29:56 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Scott Long In-Reply-To: <43677B16.4040706@samsco.org> Message-ID: <20051101152728.U45155@fledge.watson.org> References: <436116D3.908@samsco.org> <20051031151809.GA83253@stack.nl> <20051101004042.GA28233@samodelkin.net> <20051101112900.GA4903@stack.nl> <20051101123321.GA39888@samodelkin.net> <20051101130245.GE5237@stack.nl> <43677B16.4040706@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Marc Olzheim , stable@freebsd.org, Max Khon Subject: Re: HEADS UP! 6.0-RELEASE coming X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2005 15:29:58 -0000 On Tue, 1 Nov 2005, Scott Long wrote: > There is little difference between 1:1 and M:N from the application's > point of view. Both will allow multiple application threads to run > concurrently on multiple CPUs, and both will allow other process threads > to run when the current thread blocks in the kernel. The difference is > in the details with how they are scheduled and what kernel resources > they use. 1:1 has the advantage of being much less complex to implement > and maintain, while M:N has the theoretical advantage of cheaper thread > context switches. That theory hasn't panned out, though, due to > synchronization requirements and the technical requirements of proper > TLS support. I've observed at least one situation in which m:n threading has performed significantly better as a result of better use of CPU resources. Specifically, it appears (on face value) as though libpthread is avoiding over-contention of resources by limiting the number of threads entering the kernel in contentious situations on SMP. I've not yet had the opportunity to confirm this outside of micro-benchmark environments, and plan to do so in the next few weeks. This doesn't mean that this is impossible to do with libthr, just that we may need some more scheduler investigation to make libthr catch up on SMP in that environment. Details to follow as available. Robert N M Watson