Date: Thu, 10 Jan 2002 14:52:15 -0700 From: Nate Williams <nate@yogotech.com> To: Kelly Yancey <kbyanc@posi.net> Cc: Nate Williams <nate@yogotech.com>, Terry Lambert <tlambert2@mindspring.com>, Daniel Eischen <eischen@pcnet1.pcnet.com>, Dan Eischen <eischen@vigrid.com>, Peter Wemm <peter@wemm.org>, Archie Cobbs <archie@dellroad.org>, Alfred Perlstein <bright@mu.org>, arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <15422.3343.322370.370639@caddis.yogotech.com> In-Reply-To: <Pine.BSF.4.21.0201101309200.6849-100000@gateway.posi.net> References: <15421.64170.308581.606485@caddis.yogotech.com> <Pine.BSF.4.21.0201101309200.6849-100000@gateway.posi.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > See above. Even in 5.0, we're going to have some threads being switched
> > in userland context, while others are switched in the kernel. (KSE is a
> > hybrid approach that attempts to gain both the effeciency of userland
> > threads with the ability to parallelize the effeciency gains of multiple
> > CPU && I/O processing from kernel threads.
> >
> > Nate
> >
>
> OK, I'm going to stick my head in and show my ignorance. If {get,set}context
> have to be implemented as system calls, then doesn't that eliminate much, if
> not all, the gains assumed by having a separate userland scheduler?
IMO, yes.
> I mean if we've got to go to the kernel to switch thread contexts, why
> not just have the kernel track all of the threads and restore context
> once, just for the current thread, rather than twice (once for the
> scheduler and another for the scheduler to switch to the current
> thread context)?
For effeciency reasons...
Nate
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?15422.3343.322370.370639>