Date: Tue, 2 Nov 1999 13:28:01 -0800 (PST) From: Kris Kennaway <kris@hub.freebsd.org> To: Julian Elischer <julian@whistle.com> Cc: "Daniel M. Eischen" <eischen@vigrid.com>, freebsd-arch@freebsd.org Subject: Re: Threads models and FreeBSD. (Next Step) Message-ID: <Pine.BSF.4.10.9911021316330.73778-100000@hub.freebsd.org> In-Reply-To: <Pine.BSF.4.10.9911020810090.2283-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9911021316330.73778-100000>