From owner-freebsd-arch Thu Jun 27 13:21:27 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by hub.freebsd.org (Postfix) with ESMTP id B23C037B405; Thu, 27 Jun 2002 13:21:22 -0700 (PDT) Received: from pool0530.cvx21-bradley.dialup.earthlink.net ([209.179.194.20] helo=mindspring.com) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17NflV-0006ZE-00; Thu, 27 Jun 2002 13:21:17 -0700 Message-ID: <3D1B7391.38F10284@mindspring.com> Date: Thu, 27 Jun 2002 13:20:33 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Greg 'groggy' Lehey , arch@freebsd.org Subject: Re: Larry McVoy's slides on cache coherent clusters References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > Not "overly impressed" is not quite accurate.. > > "not sure that it was relevant to us" is more to the point > > He was against making the system scale to N processors where N is a large > number, stating that if corrupted the system too much to have > such fine grained locking, and that such large-scale > MP situations should be achieved with clusters of "Small-N" > machines, connected together by higher level constructs. > > I did take some mental notes from the meeting. > e.g. "make sure we don't make our kernel TOO fine grained. You should read the slides at http://www.bitmover.com/cc-pitch/ ; it should take you all of four minutes, if you skip the loading of the picture in slide 29, or if you have a fast link. He actually wants systems to be able to scale to N processors, but he believes that the way this will happen is by clustered instances of the OS, rather than running a single OS image on an indefinite number of processors. It makes sense, since his belief appears to be that at some point, a large N means that the system will be NUMA. He also makes the point that 99% of all systems are in fact not SMP (he has statistics to back this supposition), and thus there needs to be a weighting of effort relative to the user base for the resulting code. It's very intersting reading. You could actually argue that NUMA bears the same relationship to shared memory multiprocessors as shared memory multiprocessors bear to SMT processors. In all likelihood, you will have machines that are technically uniprocessor that have hyperthreading enabled in far more installations than you will ever have true SMP via multiple discrete CPUs. My personal target rests above NUMA, where there are relatively glacially slow communications channels, compared to CPU speed; this is basically the environment in which, for example, you have literally millions of processors operating from incomplete information with potentially lossy communications channels. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message