From owner-freebsd-arch Thu Jan 10 13:52:29 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id A100937B400 for ; Thu, 10 Jan 2002 13:52:17 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 535FE10DDF7; Thu, 10 Jan 2002 13:52:17 -0800 (PST) Date: Thu, 10 Jan 2002 13:52:17 -0800 From: Alfred Perlstein To: Kelly Yancey Cc: Nate Williams , Terry Lambert , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <20020110135217.M7984@elvis.mu.org> References: <15421.64170.308581.606485@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from kbyanc@posi.net on Thu, Jan 10, 2002 at 01:14:05PM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Kelly Yancey [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