From owner-freebsd-current@FreeBSD.ORG Fri Oct 27 19:39:30 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8D7116A47B; Fri, 27 Oct 2006 19:39:30 +0000 (UTC) (envelope-from prvs=julian=44840db18@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id E100F43D46; Fri, 27 Oct 2006 19:39:29 +0000 (GMT) (envelope-from prvs=julian=44840db18@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 27 Oct 2006 12:39:29 -0700 Message-ID: <45426071.7020403@elischer.org> Date: Fri, 27 Oct 2006 12:39:29 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Robert Watson References: <917908193.20061027102647@serebryakov.spb.ru> <20061027103924.F79313@fledge.watson.org> In-Reply-To: <20061027103924.F79313@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Lev Serebryakov , current@freebsd.org Subject: Re: KSE, libpthread & libthr: almost newbie question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 19:39:31 -0000 Robert Watson wrote: > > On Fri, 27 Oct 2006, Lev Serebryakov wrote: > >> I've was sure, that both libpthread and libthr use KSE to make >> multithreading. They use KSE in different ways: libpthread uses N:M >> model and libthr uses 1:1 model, but bot use KSE to work. >> How will be possible to sue these libraries (read: multithreaded >> programs) when KSE will be optional, on kernel without KSE?! > > The answer to that rather critical question, not surprisingly, is > complex. :-) > > The FreeBSD kernel actually implements a good three different threading > models (at least): > > (1) Linux threads/rfork threads. These are based on the idea of multiple > "struct proc"s floating around with varying degrees of sharing. > Typically, they share file descriptor array, address space, etc. For > those familiar with the Linux clone() system call, rfork() is > notionally > very similar. This model implies 1:1 threading, and leaves quite a > bit to > be desired in terms of overhead, as well as having some odd > implications > for POSIX-like compliance (i.e., the implementation of getpid()). > > (2) KSE. This provides a kernel<->userspace threading framework > allowing the > implementation of a broad array of threading and scheduling models. > This > is a fairly complex, but very flexible model, which has several > levels of > layering required to implement different scheduling policies using M:N > threading. Notice that 1:1 scheduling is a subset of M:N, so you can > implement 1:1 in this manner. One of the significant concerns about > KSE > is that it adds a great deal of complexity to the kernel scheduler > architecture, making it quite difficult to optimize, further > granularize > the locking for, understand, etc. > > (3) thr. This is a simpler 1:1 threading API to the kernel, which make > use of > the same architectural structures present in the kernel for KSE, but > without the full capability of M:N threading. In particular, it has > simplifying assumptions regarding how user threads enter the kernel and > are mapped into kernel threads, so doesn't need an upcall mechanism, or > create new threads when an existing thread sleeps. > > The NO_KSE patch disables the code paths required only for (2), not for > (1) or (3). One of the current theories bouncing around the kernel > developer community is that the complexity and overhead of (2) outweighs > many of the benefits of KSE, and that by making it an option, we can > better evaluate the impact. Notice that this isn't just about code > complexity, but also about scheduler overhead. David Xu has reported a > non-trivial performance change from the reduced overhead of the > scheduler paths. So now we're at a point where we can more fully > evaluate the impact of KSE (since we can actually compile it out of the > scheduler). Before anything further can be done, we now need to do that > evaluation. As I mentioned in another email, most of the complexity does not come from the M:N code, but rather from the attempt to provide process fairness. Most of David's improved speed comes not from removing teh fairness code, but from an accidental removal of a bug in the 1:1 thread support code that, in an attempt to circumvent the fainess code to improve benchmark numbers failed to do it properly, and ends up being both 'unfair" to other processes, and the recipient of all the overhead of fairness calculations. Please let's understand all this before we throw out the baby with the bathwater. > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"