From owner-freebsd-arch Sun Nov 7 6:29:57 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 CD8A314BE1 for ; Sun, 7 Nov 1999 06:29:45 -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 PAA25470 for ; Sun, 7 Nov 1999 15:29:43 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA16970 for freebsd-arch@freebsd.org; Sun, 7 Nov 1999 15:29:43 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 70F8114BE1 for ; Sun, 7 Nov 1999 06:29:26 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt36.pcnet.net [206.105.29.110]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id JAA14359; Sun, 7 Nov 1999 09:24:41 -0500 (EST) Message-ID: <38258BFA.B7EA3ECB@vigrid.com> Date: Sun, 07 Nov 1999 09:26:02 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: "Russell L. Carter" , Poul-Henning Kamp , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > > On Tue, 2 Nov 1999, Russell L. Carter wrote: [...] > > Put another way, cramming a process's threads into a single > > scheduling quanta significantly diminishes the suitability of FreeBSD > > as a platform for building high performance and/or RT CORBA apps. > > Let's rephrase this.. > > Firstly 'A single scheduling quanta' is probably a misleading statement. > > firstly it would be > 'A group of quanta' as the process may be at a priority where it gets a > lot of time and there may be only one other process with only 1 quanta > allocated to it.. > 99/100 is pretty close to all you can get.. > > secondly, I see a need to be able to effectively 'fork off a separate > family of threads' that are treated as a separate scheduling entity. > Thsi only makes sense at all if the threads in that group are explicitly > bound to that group, and other threads cannot arbitrarily wander in and > out of the group. Except for very narrow windows where threads holding critical resources (internal to the threads library) are continued until they release the resource. I can also see the need for threads to cross scheduling group boundaries in order to support priority protection and priority ceiling mutexes. > > The sum of the processing quanta for the original and the new class would > be the same as a user process forking to run 2 processes in parallel, and > would be limited by the same mechanisms. The second process could not > increaes its priority higher than the parent, just like nice(2) at the > moment. (You wuld need root priority to do that) Yes! As long as we can "obtain a new quantum" with the ability (as root) to raise priority or enter a different scheduling class, then I am satisified :-) Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message