Date: Tue, 21 Nov 2000 16:34:57 -0500 (EST) From: "Robert S. Sciuk" <rob@ControlQ.com> Cc: arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Threads (KSE etc) comments Message-ID: <Pine.BSF.4.21.0011211632570.42324-100000@schizo.controlq.com> In-Reply-To: <Pine.SUN.3.91.1001121160717.7102A-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This may be out of line, but in line with the cpu allocation question, is there (will there be) a mechanism for processor affinity determination, and changes?? This is important wrt cache coherency and producer/consumer type processes/threads. Just wondering. On Tue, 21 Nov 2000, Daniel Eischen wrote: > On Tue, 21 Nov 2000, Terry Lambert wrote: > > > yes, but that gives the ability to use M times as much CPU as a > > > nonthreaded process. > > > > If you won't give it to me, I'll just take it, instead, either > > by using rfork() and a shared memory segment for my global data, > > which gets me the equivalenet of a threaded environment, for all > > practical purposes, or I'll just fork() and run multiple instances > > of myself. Either way, you don't get to tell me not to compete > > as multiple processes, and I can throw a KSEG based policy out the > > window, without needing your permission to do it. Worse, there > > is additional context switch overhead introduced by this (the > > same reason Linux kernel threads are a bad idea), and everyone > > gets to pay the penalty for my application. > > I have to agree with Terry. You can't dictate what application > writers will do. If they want more CPU and they can't get it > with the threading model we provide, then they will get it > another way. Limiting PTHREAD_SCOPE_PROCESS threads to 1 KSEG > with only 1 quantum doesn't stop someone from [r]fork()'ing > to get more CPU. > > Let's admit that this is what some applications will want to > do and allow them to do it within our threading model. No, > we won't do it by default, but we can provide simple hooks to > allow an application to request more "CPU reservations" > (a KSEG under the current definition). > > Note that I am only talking about scope process threads. > Scope system threads are bound to their own KSEG/KSE pair. > > -- > Dan Eischen > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Robert S. Sciuk http://www.controlq.com 1032 Howard Rd. RR#2 Control-Q Research tel: 905.632.2466 Burlington, Ont. rob@controlq.com fax: 905.632.7417 Canada, L7R 3X5 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.21.0011211632570.42324-100000>