From owner-freebsd-arch Thu Jan 10 14:20:52 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 0D44437B404 for ; Thu, 10 Jan 2002 14:20:49 -0800 (PST) Received: from gateway.posi.net ([12.236.90.177]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020110222048.VJHT10199.rwcrmhc53.attbi.com@gateway.posi.net>; Thu, 10 Jan 2002 22:20:48 +0000 Received: from localhost (kbyanc@localhost) by gateway.posi.net (8.11.6/8.11.6) with ESMTP id g0AMKjp07060; Thu, 10 Jan 2002 14:20:45 -0800 (PST) (envelope-from kbyanc@posi.net) X-Authentication-Warning: gateway.posi.net: kbyanc owned process doing -bs Date: Thu, 10 Jan 2002 14:20:45 -0800 (PST) From: Kelly Yancey To: Alfred Perlstein Cc: Nate Williams , Terry Lambert , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020110135324.N7984@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Thu, 10 Jan 2002, Alfred Perlstein wrote: > * Nate Williams [020110 13:52] wrote: > > > 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... > > And flexibility as well, but I guess that can be lumped under > effeciency. > If the context switch overhead is the same (or worse) with a userland scheduler, then what are the "effeciency reasons" for having it? Where does the userland scheduler reclaim it's lost ground? The only things my limited understanding can produce are a number of trivial data structures that can be moved from the kernel to userland. :/ It seems to me that if {get,set}context involve kernel calls, then any userland scheduler would, by definition, require N+1 context switches where N is the number of context switches required by a kernel-only scheduler. The extra 1 coming from invoking the scheduler context itself. The flexibility argument I can buy, given as a trade-off of performance versus flexibility. However, I do not see where having a mixed kernel/userland scheduler can be both more flexible and more efficient in the case that it requires a syscall to switch userland contexts. And it doesn't seem proper to keep the flexibility argument if {get,set}context only work with our specific implementation of libc_r (as Peter has already noted). Of course, all this moot if userland context switches can be done properly without entering the kernel and in a way the preserves flexibility. As an aside, I cannot find a reference now, but hasn't it been rumoured that Solaris has dropped it's userland scheduler? Kelly To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message