Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Sep 2002 12:30:52 -0700 (PDT)
From:      Julian Elischer <julian@elischer.org>
To:        Rik van Riel <riel@conectiva.com.br>
Cc:        Bill Huey <billh@gnuppy.monkey.org>, freebsd-arch@freebsd.org
Subject:   Re: New Linux threading model
Message-ID:  <Pine.BSF.4.21.0209201226190.16925-100000@InterJet.elischer.org>
In-Reply-To: <Pine.LNX.4.44L.0209201112230.1857-100000@imladris.surriel.com>

next in thread | previous in thread | raw e-mail | index | archive | help


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0209201226190.16925-100000>