From owner-freebsd-arch Fri Sep 20 7:17:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C42CB37B401 for ; Fri, 20 Sep 2002 07:17:27 -0700 (PDT) Received: from 2-225.ctame701-1.telepar.net.br (2-225.ctame701-1.telepar.net.br [200.193.160.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E60143E42 for ; Fri, 20 Sep 2002 07:17:23 -0700 (PDT) (envelope-from riel@conectiva.com.br) Received: from localhost ([IPv6:::ffff:127.0.0.1]:38274 "EHLO localhost") by imladris.surriel.com with ESMTP id ; Fri, 20 Sep 2002 11:17:00 -0300 Date: Fri, 20 Sep 2002 11:16:57 -0300 (BRT) From: Rik van Riel X-X-Sender: riel@imladris.surriel.com To: Bill Huey Cc: Julian Elischer , Subject: Re: New Linux threading model In-Reply-To: <20020920100439.GB4207@gnuppy.monkey.org> Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 20 Sep 2002, Bill Huey wrote: > On Fri, Sep 20, 2002 at 12:08:38AM -0700, Julian Elischer wrote: > > HI and thanks for the pointers. > > > > it's interesting that the features that they talk about > > as being difficult and 'required' generally just "fall out" of the > > KSE implimentation. A lot of the shortcomings of M:N that they > > quote don't apply to the KSE schemes either.. > > Mingo's O(1) scheduler is pretty snazzy ( high brow technical term ;) ) > with how it migrates/load balances tasks between various CPUs, maintains > cache coherency, What's maybe more important about the O(1) scheduler is that it doesn't try to recalculate the priority of all processes once in a while, like the FreeBSD scheduler and the old Linux scheduler. There don't seem to be any O(n) loops left in or near this scheduler, meaning that 1:1 threading with lots of threads becomes possible. > > What they have decided to do is not a stupid move. But I disagree with > > It's a good political move on their part because of the orientation of > their kernel community. Their kernel context switching time is very > fast, 2x faster than NetBSD from what I saw, so it's probably a workable > solution for them with something like their "futex" performance being > the only funny question left unanswered. Futexes are very nice. In the uncontended case (should be the normal case, if your semaphores are always contended you've got worse problems) there is NO kernel overhead involved in grabbing the lock ... you just do the same atomic operations involved with grabbing a spinlock. Only in the contended case will a futex fall back to sleeping in kernel space. This kind of very low overhead locking might be useful for FreeBSD too, if it isn't yet integrated into the KSE model. As for which threading model to use ... I wouldn't worry about that too much, I suspect either the Linux 1:1 model or the M:N model used by KSE will work just fine for pretty much all applications. cheers, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Spamtraps of the month: september@surriel.com trac@trac.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message