Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 2 Dec 2001 16:09:19 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 2 Dec 2001 16:09:07 -0500 Received: from mail.xmailserver.org ([208.129.208.52]:6148 "EHLO mail.xmailserver.org") by vger.kernel.org with ESMTP id ; Sun, 2 Dec 2001 16:09:02 -0500 Date: Sun, 2 Dec 2001 13:19:43 -0800 (PST) From: Davide Libenzi X-X-Sender: davide@blue1.dev.mcafeelabs.com To: Larry McVoy cc: Horst von Brand , lkml Subject: Re: Linux/Pro [was Re: Coding style - a non-issue] In-Reply-To: <20011202122940.B2622@work.bitmover.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 2 Dec 2001, Larry McVoy wrote: > On Sat, Dec 01, 2001 at 08:05:59PM -0300, Horst von Brand wrote: > > Larry McVoy said: > > > > [...] > > > > > Because, just like the prevailing wisdom in the Linux hackers, they thought > > > it would be relatively straightforward to get SMP to work. They started at > > > 2, went to 4, etc., etc. Noone ever asked them to go from 1 to 100 in one > > > shot. It was always incremental. > > > > Maybe that is because 128 CPU machines aren't exactly common... just as > > SPARC, m68k, S/390 development lags behind ia32 just because there are > > many, many more of the later around. > > > > Just as Linus said, the development is shaped by its environment. > > Really? So then people should be designing for 128 CPU machines, right? > So why is it that 100% of the SMP patches are incremental? Linux is > following exactly the same path taken by every other OS, 1->2, then 2->4, > then 4->8, etc. By your logic, someone should be sitting down and saying > here is how you get to 128. Other than myself, noone is doing that and > I'm not really a Linux kernel hack, so I don't count. > > So why is it that the development is just doing what has been done before? That's exactly the Linus point: no long term preventive design. That means short term design on what we actually have or on what we can think available in a very near future. Because, again, if you start designing now an SMP solution for 128 CPUs, you're going to model it on the current technology that won't probably fit in future SMP architectures and you'll be screwed up. There should be a reason why software evolves in this way, think about it. Either everyone else is fool or you're the prophet. And if you're the prophet and you think that the future of multiprocessing is UP on clusters, why instead of spreading your word between us poor kernel fans don't you pull out money from your pocket ( or investors ) and start a new Co. that will have that solution has primary and unique goal ? You could be the J.C. Maxwell of the next century. - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/