Date: Thu, 19 Apr 2001 10:10:51 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Dennis <dennis@etinc.com> Cc: freebsd-hackers@FreeBSD.org, Kris Kennaway <kris@obsecurity.org>, Alfred Perlstein <bright@wintelcom.net>, Rik van Riel <riel@conectiva.com.br> Subject: Re: SMP in 2.4 (fwd) Message-ID: <XFMail.010419101051.jhb@FreeBSD.org> In-Reply-To: <5.0.2.1.0.20010419114632.03cacdd0@mail.etinc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 19-Apr-01 Dennis wrote: > At 10:17 PM 04/18/2001, Rik van Riel wrote: >>On Wed, 18 Apr 2001, Dennis wrote: >> >> > >You think Intel isn't going to market dual/quad ia64 machines? >> > >> > Yes, but who'll need them? >> >>If nobody needed them, what would be the point in SELLING >>them ? >> >>I know you don't trust our technical instinct, but you might >>at least consider the business instinct of companies like >>Intel, IBM or Unisys (who all sell big SMP systems). > > I didnt say they shouldnt support SMP, only that complicating the OS with > highly SMP-specific code to make it slightly more efficient when 99% of > users dont need it is a questionable endeavor. We are not complicating the OS. In fact, in many cases, we are cleaning up and simplifying the kernel internals. For example, the way we handle clock interrupts is very ugly and hacky on SMP x86, and the changes in SMPng have allowed me to clean it up and simplfly it greatly in a manner that allows us to share code with both alpha and x86 SMP support and avoid potential deadlocks and races in the x86 SMP code. >>And as for the "but you can wait 2 years until UP is faster than >>today's SMP" doesn't quite work for eg. investment banking and >>stock funds. More computing power means better calculations, which >>means more money. And for folks like them, computing power is not >>measured in FLOPS, but in ACRES. And when you're talking 3 acres >>of computing power, you'd better have some decend density (ie. SMP >>in 2U rackmounted boxes, or something similarly suitable). > > Your point is moot, as you already have SMP support. The question is > whether squeezing a few extra cycles out (SMPng) is worth making the OS > significantly more complex, particularly when more computing power is > always on the way. We aren't squeezing a few extra cycles out, we are squeezing a buttload of cycles out in the SMP case. Do you even know how the SMP support works? If all the CPU's want to make a system call at the same time, only one of them does any work, all the other CPU's sit _idle_ doing _absolutely_ _zero_ _productive_ _work_ but still sucking juice. > I understand there is a language thing, but I went out of my way to say > that i wasnt saying that SMP shouldnt be supported. It already is, and its > been done very cleanly in a way that doesnt compromise the integrity of the > OS internals. Actually, it's done in about the most inefficient manner possible, to be brutally honest. The first stage of the SMP support focused more on getting the machine to run than on getting it to perform well. You really should go do some actual research on SMP before spouting off. I highly recommend Curt Schimmel's _Unix Systems for Modern Architectures_: Caching and SMP for Kernel Programmers. If you read it, you will find that our current implementation is actually worse than a master/slave kernel setup, which is the slowest one mentioned in the book. :( Please, go do some actual research so you can at least spout off some semi-clueful nonsense rather than completely clueless nonsense. > DB -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010419101051.jhb>