Date: Wed, 5 Feb 2003 12:54:10 -0800 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: Narvi <narvi@haldjas.folklore.ee> Cc: Dag-Erling Smorgrav <des@ofug.org>, freebsd-chat@FreeBSD.ORG Subject: N:M vs. 1:1 threading (was: Re: Project status) Message-ID: <20030205205410.GA1825@HAL9000.homeunix.com> In-Reply-To: <20030205201148.F43637-100000@haldjas.folklore.ee> References: <xzp4r7kuf3l.fsf@flood.ping.uio.no> <20030205201148.F43637-100000@haldjas.folklore.ee>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Narvi <narvi@haldjas.folklore.ee>:
>
> On Tue, 4 Feb 2003, Dag-Erling Smorgrav wrote:
>
> > - KSE ("kernel scheduled entities") is a threading architecture, both
> > for in-kernel threads and for mapping userland threads onto kernel
> > threads (which allows splitting one application across multiple
> > CPUs; our current thread library doesn't). I don't know of any
> > substantial opposition against KSE. There are some concerns that
> > the M-on-N model is not really better than the 1-on-1 model,
> > especially now that Solaris has switched to the latter, and that
> > KSE is over-engineered and possibly out of the reach of a team of
> > (relatively) amateur volunteers. Otherwise, complaints regarding
> > KSE are mostly about how much time it's taking to implement, and
> > concerns that the KSE developers aren't subjecting their code to
> > sufficient testing before committing it. Note that I'm neither
> > confirming or refuting any of these claims, just reporting what
> > other people are saying about KSE.
> >
>
> the N:M and especially the 1:1 models are also slightly simplified
> pictures. I think this is also a cyclical development problem - at some
> point using 1:1 threads is insufficent and/or doesn't give acceptable
> perfomace so the move to N:M happens. At some point later, kernel based
> threads are again sufficently perfomant that N:M becomes unnecessary
> complexity.
>
> Linux/*BSD are just a cycle behind Solaris in this area. Ultimately the
> cycles don't matter, what matters is the perfomance and capabilities you
> deliver.
Actually, in the case of Solaris, bugs are what matter. After all
of these years, they never ironed all of the nits out of the LWP
implementation, but their 1:1 threading implementation just works,
and has no outstanding problem reports. Maybe FreeBSD will have
the same problems. But from a performance point of view, you can
get much cheaper threads, with fewer protection boundary crossings
and cheaper context switches, with a UTS. SA happens to be a very
nice abstraction for getting it right (LWPs that really are
/light/) and hopefully that is reflected in what we will
eventually get.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030205205410.GA1825>