From owner-freebsd-arch Thu Jan 10 14:36:17 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 2F99337B400 for ; Thu, 10 Jan 2002 14:36:13 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id PAA08428; Thu, 10 Jan 2002 15:36:02 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0AMa1K00357; Thu, 10 Jan 2002 15:36:01 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15422.5969.820708.433083@caddis.yogotech.com> Date: Thu, 10 Jan 2002 15:36:01 -0700 To: Kelly Yancey Cc: Alfred Perlstein , 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: References: <20020110135324.N7984@elvis.mu.org> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) 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 > > > > 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? *IF* it requires a system call/kernel help, then we have no choice. However, the reason we're spending some much time determining if this necessary is because of effeciency/flexibility reasons. If we can do it in userland, then we should have the option of doing it there. > 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. :/ There is debugging and flexibility to be gained by having it in userland as well. You can change the way a particular process wants it's threads scheduled much easier in a userland scheduler by changing the algorithm, since it doesn't require a kernel recompile/reboot. Plus, each application may want a specific threading algorithm used. > Of course, all this moot if userland context switches can be done properly > without entering the kernel and in a way the preserves flexibility. Right. > As an aside, I cannot find a reference now, but hasn't it been > rumoured that > Solaris has dropped it's userland scheduler? I hadn't heard that. However, I had heard that they were providing an alternative thread library that uses a one-one mapping for user/kernel threads for certain applications. In this case, there would be no reason for a userland thread scheduler. I don't believe this is the only model they support though... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message