Date: Fri, 10 Dec 1999 21:55:29 -0700 From: Nate Williams <nate@mt.sri.com> To: Chuck Robey <chuckr@picnic.mat.net> Cc: Nate Williams <nate@mt.sri.com>, Arun Sharma <adsharma@sharmas.dhs.org>, freebsd-arch@freebsd.org Subject: Re: Thread scheduling Message-ID: <199912110455.VAA24095@mt.sri.com> In-Reply-To: <Pine.BSF.4.10.9912102103490.16082-100000@picnic.mat.net> References: <199912110135.SAA23495@mt.sri.com> <Pine.BSF.4.10.9912102103490.16082-100000@picnic.mat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > It is desirable for effeciency reasons (if two threads are running on > > seperate CPU's, then twice as much work will get done), as well as the > > cache issues. But, is making it a requirement desirable? Not in my > > book. (I may have misunderstood your 'desirable' statement previously > > by reading that making assuming that you were wondering if is desirable > > to make it a requirement, which is silly now that I think about it.) > > OK, let me state it again. I wasn't asking if it was a good thing to > share out threads among multiple processors, because the advantages of > using a multiple CPU system *as* a multiple CPU seem obvious enough not to > need asking. Except that it's possible that you may want to limit multiple-CPU's to multiple processes for cache reasons. Once could argue that for certain classes of threaded applications, you'd get a better hit rate by sticking with a single CPU for *all* of the threads, although this wouldn't be true for all threaded applications. It depends on the application. > I was asking to see if it would be a good thing to add a > strong bias to the system, in such a way as to make the co-scheduling of > threads among the different processors so that all processors that are > made available to the program's threads are executing in that address > space as the same moment in time. I wouldn't think it would help for cache rate and/or CPU usage, but that's just a gut feeling and not based on anything else. Each CPU in an SMP system has it's own cache, so what happens on another CPU shouldn't effect how the one CPU performs. Adding this bias wouldn't help, and may in fact make things worse (see above). > Not a guarantee, but would it be a good thing to have them > "co-scheduled" (or a bias towards that likelihood). But, I can't see any advantage to have them co-scheduled. Nate 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?199912110455.VAA24095>