Date: Tue, 22 Jun 1999 18:35:27 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: gsutter@pobox.com (Gregory Sutter) Cc: tlambert@primenet.com, dvwd@wwdg.com, freebsd-questions@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: Multi processor support? Message-ID: <199906221835.LAA25521@usr05.primenet.com> In-Reply-To: <19990621182054.G73528@001101.zer0.org> from "Gregory Sutter" at Jun 21, 99 06:20:54 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Also, is there any way to control what processes happen on > > > which cpu? > > > > Heh. That wouldn't be very symmetric... > > No, but having processor affinity would be quite nice. There's > nothing wrong with MP. Processor afinnity is not the same thing as locking a process to a CPU (affinity means that it prefers to stay on the same CPU, as opposed to being forced to stay on the same CPU no matter how loaded that CPU gets vs. the relative cost of a cache bust. Unless you are engaged in L1/L2 cache-busting behaviour (not possible with one process), then locking to a particular CPU buys you only assymetry (kind of like wearing a jaunty hat). INRE: The previous question about one FORTRAN process using multiple CPU's in Linux being better than that on FreeBSD: not possible at the present time. The point is that in order for a single program to benefit from SMP, you must either engage in static scheduling, e.g.: | Compile-time Partitioning and Scheduling of Parallel Programs | V. Sarkar and J. Hennessy | Proceedings of the SIGPLAN '88 Symposium on Compiler | Construction, 1986, pages 17-26 | Compile-Rime Scheduling and Assignment of Data-Flow Program | Graphs | S. Ha and E.A. Lee | IEEE Transactions on Computers, November 1991, pages 1225-1238 Or you must engage in task granularization and partitioning, e.g.: | On the Granularity and Clustering of Directed Acyclic Task | Graphs | A. Gerasoulis and T. Yang | IEEE Transactions on Parallel and Distributed Systems, June | 1993, pages 686-701 | Grain Size Determination for Parallel Processing | B. Kruatrachue and T. Lewis | IEEE Software, January 1988, pages 23-32 | Lazy Task Creation: A Technique for increasing Granularity | of Parallel Programs | E. Mohr, D.A. Kranz, and R.H. Halstead, Jr. | IEEE Transactions on Parallel and Distributed Systems, July | 1991, pages 264-280 (Note: this last describes the method used for lazy kernel thread creation utilized by BSDI -- only 8 years behind the literature). Or you must use scheduling tools, e.g.: | PARSA: A Parallel Program Software Development Tool | B. Shirazi et al. | Proceedings 1994 Symposium on Assessment of Quality Software | Development Tools, 1994, pages 96-111 | Parafrase-2: An Environment for Parallelizing, Partitioning, | Synchronizing, ans Scheduling Programs on Multiprocessors | C.D. Polychronopoulos et al. | Proceedings 1989 International Conference on Parallel | Processing In other words, you need help from your tools, and the GNU FORTRAN compiler just isn't going to cut it. Neither is a commercial FORTRAN compiler without explicit knowledge of the task architecture implemetnation so that it know where to do the trade-offs. The best you are going to get is explicit division of tasks between multiple processes. At *that* point (and *only* then) does CPU affinity become a real issue. Even so, it's not an issue addressed (IMO) by the Linux SMP implementation (any more than the FreeBSD or BSDI implementations). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906221835.LAA25521>