From owner-freebsd-arch Sun Nov 7 2:47:20 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 8BACC14CEA for ; Sun, 7 Nov 1999 02:47:18 -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 LAA23701 for ; Sun, 7 Nov 1999 11:47:17 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id LAA16098 for freebsd-arch@freebsd.org; Sun, 7 Nov 1999 11:47:16 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 3313B14CEA for ; Sun, 7 Nov 1999 02:47:11 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id CAA58415; Sun, 7 Nov 1999 02:45:06 -0800 (PST) Date: Sun, 7 Nov 1999 02:45:04 -0800 (PST) From: Julian Elischer To: "Russell L. Carter" Cc: Poul-Henning Kamp , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) In-Reply-To: <19991102143819.5D0F23B@chomsky.pinyon.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 2 Nov 1999, Russell L. Carter wrote: > %In message <381EDBCE.FD7FBA68@vigrid.com>, "Daniel M. Eischen" writes: > % > %>> >Disagree. I want lightweight processes to have their own quantum > %>> >not limited (in total) to the parent process quantum. > %>> > %>> That would clearly kill the "lightweight" in "lightweight process"... > %> > %>That doesn't mean they each have to have the same quantum as a non-MT > %>process. > % > %That has nothing to do with it. > % > %There is not much point in making a lightweight process facility > %if the resulting processes are not lightweight. > > Then the application developer should choose libc_r threads. > > There isn't much point to doing this effort if the > pthread_*sched* functions don't actually mean much in the > global context. > > People building large scale distributed objects that > are also high performance require fine grained schedulability > of individual threads. I can provide references that demonstrate > how low level thread scheduling architecture > affect high level services. > > Solaris, HP, MVS, and Linux support this to varying degrees now. > The RT-OSs more or less do, though some fail in surprising ways. > Linux is surprisingly good. > > 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. 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) > > Regards, > Russell > > > > %-- > %Poul-Henning Kamp FreeBSD coreteam member > %phk@FreeBSD.ORG "Real hackers run -current on their laptop." > %FreeBSD -- It will take a long time before progress goes too far! > % > % > % > % > %To Unsubscribe: send mail to majordomo@FreeBSD.org > %with "unsubscribe freebsd-arch" in the body of the message > % > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message