From owner-freebsd-arch Tue Nov 2 9:55:46 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 76EF414D37 for ; Tue, 2 Nov 1999 09:55:40 -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 SAA24177 for ; Tue, 2 Nov 1999 18:55:38 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA81444 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 18:55:38 +0100 (MET) Received: from plunger.gdeb.com (plunger.gdeb.com [153.11.11.3]) by hub.freebsd.org (Postfix) with ESMTP id CCADB14CD3 for ; Tue, 2 Nov 1999 09:55:06 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from orion.caen.gdeb.com ([153.11.109.11]) by plunger.gdeb.com with ESMTP id MAA01957; Tue, 2 Nov 1999 12:28:37 -0500 (EST) Received: from vigrid.com (clcrtr [153.11.109.129]) by orion.caen.gdeb.com (8.9.3/8.9.3) with ESMTP id MAA44908; Tue, 2 Nov 1999 12:53:22 -0500 (EST) (envelope-from eischen@vigrid.com) Message-ID: <381F2512.885AC9F@vigrid.com> Date: Tue, 02 Nov 1999 12:53:22 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.51 [en] (X11; U; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jason Evans Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) References: <381ED720.5A24A02B@vigrid.com> <19991102084756.Z729@sturm.canonware.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jason Evans wrote: > > The ultimate goal of M:N thread scheduling (thread:LWP), as in OSes such as > Solaris, is to allow simultaneous execution of threads on (ideally) all the > processors in a system. That is, the goal should be M:P scheduling, > (thread:processor). As such, Solaris's LWP approach does a statistically > acceptable job of using the available processors, but from a pragmatic > point of view, it's a very complex (and high overhead) solution to the > problem. In my opinion, Solaris's solution is not ideal, and we should > strive to do better. We currently have only user based threads. A Solaris-like implementation would be much better than what we have now. Perhaps we really do need some definitions. We need more than one "schedulable entity" to be able to run simulataneously on multiple processor. > > > 6/ (contentious) multiple theads should be bound to within the resource > > > limits of the single process. > > > > Disagree. I want lightweight processes to have their own quantum > > not limited (in total) to the parent process quantum. > > I disagree with your disagreement. =) First, as explained above, I don't > think we should be talking in terms of LWPs. I needed _some_ term to mean "schedulable entity", within which a PTHREAD_SCOPE_SYSTEM thread could run. > Second, from a view external > to the kernel, to treat a single-threaded process as a second class citizen > IMO breaks the notion of process scheduling. Of course, depending on the > implementation we go with, process accounting may be difficult to do > "correctly", so some compromise may be necessary. And what about an application that forks/rforks? It becomes supreme being and that's OK ;-) Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message