Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 10 Jan 2002 13:52:17 -0800
From:      Alfred Perlstein <bright@mu.org>
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>, arch@FreeBSD.ORG
Subject:   Re: Request for review: getcontext, setcontext, etc
Message-ID:  <20020110135217.M7984@elvis.mu.org>
In-Reply-To: <Pine.BSF.4.21.0201101309200.6849-100000@gateway.posi.net>; from kbyanc@posi.net on Thu, Jan 10, 2002 at 01:14:05PM -0800
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
* Kelly Yancey <kbyanc@posi.net> [020110 13:14] wrote:
> On Thu, 10 Jan 2002, Nate Williams wrote:
> 
> > 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.
> > 
> 
>   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? 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)?

That's the point of this discussion, we're trying to figure out
why and if possible how to avoid them being system calls. :)

Basically what it seems to come down to are two points:

1) Is atomicity required?  (looks like a "no")
2) Are states like FP usage trackable from userspace?
   (looks like a "yes" with some kernel help)

-- 
-Alfred Perlstein [alfred@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
 start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductable donations for FreeBSD: http://www.freebsdfoundation.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?20020110135217.M7984>