From mboxrd@z Thu Jan 1 00:00:00 1970 From: tlaronde@polynum.com Date: Sun, 19 Apr 2009 22:11:51 +0200 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20090419201151.GA3167@polynum.com> References: <4f34febc0904190058u1507f60fldc51ab3eab1f09fe@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Subject: Re: [9fans] "FAWN: Fast array of wimpy nodes" (was: Plan 9 - the next 20 years) Topicbox-Message-UUID: e95c99f2-ead4-11e9-9d60-3106f5b1d025 On Sun, Apr 19, 2009 at 09:27:43AM -0500, Eric Van Hensbergen wrote: > > I'm not convinced that such ad-hoc DSM models are the way to go as a > general principal. Full blown DSM didn't fair very well in the past. > Plan 9 distributed applications take a different approach and instead > of sharing memory they share services in much more of a message > passing model. This isn't to say that all caches are bad -- I just > don't believe in making them the foundation of your programing model > as it will surely lead to trouble. > FWIW, the more satisfying definition for me of a "computing unit" (an "atom" OS based) is memory based: all the processing unit having direct hardware access to a memory space/sharing the same directly hardware accessible memory space. There seems to be 2 kinds of "NUMA" around there : 1) Cathedral model NUMA: a hierarchical association of memories, tightly coupled but with different speeds (a lot of uniprocessor are NUMA these days with cache1, cache2 and main memory). All directly known by the cores. 2) Bazaar model NUMA, or software NUMA, or GPLNUMA: treating an inorganized collection of storage as addressable memories since one can always give a way to locate the ressource, including by URL, associating high speed tightly connected memories with remote storage accessible via IP packets sent by surface mail if the hardware drived whistle is heard by the human writing the letters. Curiously enough, I believe in 1. I don't believe in 2. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C