Date: Wed, 5 Feb 2003 23:32:46 +0200 (EET) From: Narvi <narvi@haldjas.folklore.ee> To: David Schultz <dschultz@uclink.Berkeley.EDU> Cc: Dag-Erling Smorgrav <des@ofug.org>, <freebsd-chat@FreeBSD.ORG> Subject: Re: N:M vs. 1:1 threading (was: Re: Project status) Message-ID: <20030205231546.U43637-100000@haldjas.folklore.ee> In-Reply-To: <20030205205410.GA1825@HAL9000.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 5 Feb 2003, David Schultz wrote:
> 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,
LWP-s *are* the M part in N:M, and the threads in the 1:1 case. The 1:1
case really just makes sure the N is never larger than M by assigning all
threads a LWP (all threads a bound threads).
> 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.
>
Like I said - its a perfomace trade-off 8-)
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?20030205231546.U43637-100000>