From owner-freebsd-arch Fri Sep 20 12:40:15 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 25A7437B401 for ; Fri, 20 Sep 2002 12:40:13 -0700 (PDT) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6AE443E42 for ; Fri, 20 Sep 2002 12:40:12 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020920194012.OODP8126.rwcrmhc53.attbi.com@InterJet.elischer.org>; Fri, 20 Sep 2002 19:40:12 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA20258; Fri, 20 Sep 2002 12:30:53 -0700 (PDT) Date: Fri, 20 Sep 2002 12:30:52 -0700 (PDT) From: Julian Elischer To: Rik van Riel Cc: Bill Huey , freebsd-arch@freebsd.org Subject: Re: New Linux threading model In-Reply-To: Message-ID: 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, Rik van Riel wrote: > On Fri, 20 Sep 2002, Bill Huey wrote: > > On Fri, Sep 20, 2002 at 12:08:38AM -0700, Julian Elischer wrote: > 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. The FreeBSD scheduler is moving towards a big rewrite but we want to change "one thing at a time" :-) in that area.. > > > > 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. We will probaly have to implementn futexes, at least we will have to implement the kernel side of it, so that linux emulation can continue to work. Having done that We'll probabyl make a similar user-landn side available for the threading libraries to use too. > > 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. That is true and it will be a very intersting experiment to see how the corner-cases work out... > > 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