Skip site navigation (1)Skip section navigation (2)
From:      Rik van Riel <riel@conectiva.com.br>
To:        Bill Huey <billh@gnuppy.monkey.org>
Cc:        Julian Elischer <julian@elischer.org>, <freebsd-arch@freebsd.org>
Subject:   Re: New Linux threading model
Message-ID:  <Pine.LNX.4.44L.0209201112230.1857-100000@imladris.surriel.com>
In-Reply-To: <20020920100439.GB4207@gnuppy.monkey.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.44L.0209201112230.1857-100000>