Date: Thu, 19 Apr 2001 11:56:09 -0400 From: Dennis <dennis@etinc.com> To: Rik van Riel <riel@conectiva.com.br> Cc: Alfred Perlstein <bright@wintelcom.net>, Kris Kennaway <kris@obsecurity.org>, freebsd-hackers@FreeBSD.ORG Subject: Re: SMP in 2.4 (fwd) Message-ID: <5.0.2.1.0.20010419114632.03cacdd0@mail.etinc.com> In-Reply-To: <Pine.LNX.4.21.0104182313560.1685-100000@imladris.rielhome. conectiva> References: <5.0.2.1.0.20010418190439.03633920@mail.etinc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >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. 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. DB 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?5.0.2.1.0.20010419114632.03cacdd0>