Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 27 Apr 2001 13:34:33 -0700
From:      Alfred Perlstein <bright@wintelcom.net>
To:        Nate Williams <nate@yogotech.com>
Cc:        Daniel Eischen <eischen@vigrid.com>, Matt Dillon <dillon@earth.backplane.com>, Julian Elischer <julian@elischer.org>, Arch@FreeBSD.ORG
Subject:   Re: KSE threading support (first parts)
Message-ID:  <20010427133433.H18676@fw.wintelcom.net>
In-Reply-To: <15081.53821.755743.746621@nomad.yogotech.com>; from nate@yogotech.com on Fri, Apr 27, 2001 at 02:10:37PM -0600
References:  <15081.50170.297579.938254@nomad.yogotech.com> <Pine.SUN.3.91.1010427154434.12501B-100000@pcnet1.pcnet.com> <20010427130826.G18676@fw.wintelcom.net> <15081.53821.755743.746621@nomad.yogotech.com>

next in thread | previous in thread | raw e-mail | index | archive | help
* Nate Williams <nate@yogotech.com> [010427 13:14] wrote:
> > > > >     Well, that's complete bullshit.  KSE's are extremely short-running
> > > > >     affairs in kernel mode, especially when you consider the most likely
> > > > >     asynchronizing case (a simple blocking situation that will most commonly
> > > > >     be in a read() or write()).
> > > > 
> > > > Not necessarily.  My experience with developing and running applications
> > > > on Solaris says that having multiple KSE's/process is a *huge* win.
> > > 
> > > You do know that the proposed implementation isn't quite like
> > > Solaris (KSEs don't get their own quantum).  You better holler
> > > if you want it ;-)
> > 
> > There's two things on the issue that I'd like to bring up.
> > 
> >    The concepts are cool, however the implementation you guys are
> >    discussion really hurt my head, not in a bad way, but conceptually
> >    the concepts look quite daunting.  Kudos if you guys get it done
> >    though!
> > 
> >    Being able to have threads used in a "this application wants to
> >    utilize _all_ available system reasources" meaning if you have
> >    more than one processor, I want to see mysql, apache, whatever
> >    using it (by default!).  If your model doesn't include this then
> >    please don't bother continuing, the stability issues versus the
> >    gain don't work for me at all.
> 
> Having 'serialized' KSE's (which Matt wants) means that an application
> will be *UNABLE* to use all of the system resources, because only one
> thread in threaded application (apache, mysql, etc..) is allowed to run
> at one time, no matter how many CPU's are there.

It doesn't seem like that's what Daniel is saying, which is that
the default will be like this, but that applications or the startup
code will have the choice.

However that's true then we might as well scrap the project, it
just brings the complexity out of userland and into the kernel,
sure we can schedule IO better, but then we might as well cop out
and use aio and some special signal system for handling faults back
into the uts.  It's just a lot simpler to go with rfork threads or
a simpler model than all this complexity just to satisfy Terry's
view of who should get what quantum.  Honestly if you ask anyone
they expect to be able to cheat with threads the same way they
cheat by using multiple processes to gain additional CPU.

-- 
-Alfred Perlstein - [alfred@freebsd.org]
Daemon News Magazine in your snail-mail! http://magazine.daemonnews.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?20010427133433.H18676>