From owner-freebsd-arch Mon Nov 29 8:12: 9 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 70FE214CAE for ; Mon, 29 Nov 1999 08:12:06 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id RAA20719 for ; Mon, 29 Nov 1999 17:12:05 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA64476 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 17:11:45 +0100 (MET) Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 028E21501D for ; Mon, 29 Nov 1999 08:11:22 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id JAA09041; Mon, 29 Nov 1999 09:11:18 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id JAA19058; Mon, 29 Nov 1999 09:11:13 -0700 Date: Mon, 29 Nov 1999 09:11:13 -0700 Message-Id: <199911291611.JAA19058@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: Jason Evans , "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: References: <19991124220406.X301@sturm.canonware.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > This sounds similar to Solaris LWPs in that there are potentially KSEs > > blocked in the kernel, whereas with scheduler activations (SA), that > > doesn't happen under normal circumstances. > > No, under SA KSE's block. and another KSE is generated to act as a > replacement. it is used to run the activation that is passed to the > scheduler, and this the next thread the process runs. That's not how I read the paper. I think we all might be on the 'same page', but I think we're all using different terminology. How's about we define what a KSE is, a SA is, and come up with some other term for a userland 'thread'? It seems that Julian is using the same term for a userland thread and a context that can go into the userland as a KSE, but I'm not sure. Assuming for a moment that this is the case, then is a SA a 'kernel context' that wraps up a KSE when it goes 'live' (the UTS schedules it)? If so, then the KSE and the SA are essentially the same thing, aren't they? > there must be. > there is a stack that must be saved, and registers. this is a KSE. > > > The syscall context has some kernel context, but there is no bonifide > > context, such as with Solaris's LWP model. When the syscall completes, a > > new activation is created for the upcall to the UTS. > > A KSE is basicaly saved proocessor state, including a stack, and some > linkage points to allow that to be hug of various other structures, e.g. > sleep queues, procs , subprocs, etc. How does the UTS allow another thread to use this 'KSE' when *IT* decides to allow another user0land thread to run? As I read the SA paper, this is how things are done. > > That said, I disagree with the idea of the UTS having explicit control over > > scheduling of KSEs. Hmm.... I think that there should be exactly one KSE per > > processor (with the exception of PTHREAD_SCOPE_SYSTEM (bound) threads), and > > that threads should be multiplexed onto the KSEs. This lets the kernel > > schedule KSEs as it sees fit, and lets the UTS divide the runtime of the > > KSEs as it sees fit. How does the UTS 'divide' the runtime if it isn't allowed to schedule the KSE? What is the difference between 'schedule' and 'divide'? Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message