From owner-freebsd-arch Tue Nov 2 13:28:29 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 82FEF15340 for ; Tue, 2 Nov 1999 13:28: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 WAA27326 for ; Tue, 2 Nov 1999 22:28:17 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA82455 for freebsd-arch@freebsd.org; Tue, 2 Nov 1999 22:28:17 +0100 (MET) Received: by hub.freebsd.org (Postfix, from userid 758) id 064FB15470; Tue, 2 Nov 1999 13:28:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id ED84C1CD75C; Tue, 2 Nov 1999 13:28:01 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Tue, 2 Nov 1999 13:28:01 -0800 (PST) From: Kris Kennaway To: Julian Elischer Cc: "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) In-Reply-To: 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, Julian Elischer wrote: > > Disagree. I want lightweight processes to have their own quantum > > not limited (in total) to the parent process quantum. > > Most people disagree with you on this one, so if you want what you > describe, you will have to thik of a way of decribing it as an optional > characteristic. We discussed this and the overwhelming majority decided > that a threaded program has no real scheduling advantage over a non > threaded program, oth that what it get's by teh nature of blockin gless > and being on multiple CPUs. Having said that, it is possible that you want > your threaded proggram to hog the system (the sysadmin may disagree, in > which case you must still be bound by your process limits). Should this be > the case, you should be able to specify some optional (non > default) characteristic that allows this.. If you can thinkk of a good way > of describing this, we can include it.. (but it can't be the default > behaviour as far as I can see.) If we were using a Solaris-like model where you can have arbitrarily many kernel threads (KSEs) then this shouldn't be the default behaviour, you're right - perhaps we should add a "backwards compatability"/"no breaking of UNIX semantics" item to the list of design goals. If you can generate M>N kernel threads on behalf of your process then you can starve other processes in the system. But I can see that there are situations where you might want this behaviour; to make maximum use of the hardware you (as a process) don't want your various KSEs competing with each other for scheduling quanta, but competing equally with the other KSEs on the system. In terms of scheduler activations, the system ONLY allocates as many "live" (non-blocked) activations (KSEs) as there are processors, so if your process has more than one activation that means it's yours to use until it's taken away from you, independent of whatever other KSEs in your process are doing. So this becomes a non-problem. Kris ---- Cthulhu for President! For when you're tired of choosing the _lesser_ of two evils.. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message