From owner-freebsd-arch Mon Nov 29 8:22:32 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 47847150FC for ; Mon, 29 Nov 1999 08:22:28 -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 RAA20838 for ; Mon, 29 Nov 1999 17:22:27 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA64551 for freebsd-arch@freebsd.org; Mon, 29 Nov 1999 17:22:26 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id D657A151A2 for ; Mon, 29 Nov 1999 08:21:33 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id IAA06301; Mon, 29 Nov 1999 08:21:30 -0800 (PST) (envelope-from dillon) Date: Mon, 29 Nov 1999 08:21:30 -0800 (PST) From: Matthew Dillon Message-Id: <199911291621.IAA06301@apollo.backplane.com> To: Nate Williams Cc: Julian Elischer , Jason Evans , "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads References: <19991124220406.X301@sturm.canonware.com> <199911291611.JAA19058@mt.sri.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> > 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 The terminology I have been using, which I thought was the same as Julian's but may not be, is: Thread Two entities. A kernel structure 'Thread' and also a similarly named but independant user structure within the UTS. KSE A kernel scheduleable entity. I was using this to mean the contextual information (such as a kernel stack) required for the kernel to be able to run a thread. Not required for runnability, only required to actually run the thread and also held over of the thread blocks while in the kernel. Process Our good old process. I think I actually misspoke earlier. Runnability in the kernel scheduler is governed by 'Thread', not 'KSE' with my idea. Only currently running contexts require a KSE. i.e. you might have 10 runnable Threads linked into the kernel's scheduler but if you have a two-cpu system, only 2 of those 10 will actually be running at any given moment and require KSE's. With my system we change the kernel scheduling entity from a 'Process' to a 'Thread' and a Thread can then optionally (dynamically) be assigned a KSE as required to actually run. The KSE is a kernel abstraction and essentially *invisible* to user mode. The Thread is a kernel abstraction that is visible to user mode. With Julian's idea the kernel scheduling entity remains a 'Process', KSE's are special cases within that process, and Threads appear to be entirely userland entities. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message