9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: tlaronde@polynum.com
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] "FAWN: Fast array of wimpy nodes" (was: Plan 9 - the next 20 years)
Date: Sun, 19 Apr 2009 22:11:51 +0200	[thread overview]
Message-ID: <20090419201151.GA3167@polynum.com> (raw)
In-Reply-To: <a4e6962a0904190727p339e2793i96fd3f9c9352c966@mail.gmail.com>

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) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C



  reply	other threads:[~2009-04-19 20:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-19  7:58 John Barham
2009-04-19 12:16 ` erik quanstrom
2009-04-19 15:43   ` John Barham
2009-04-19 16:52     ` erik quanstrom
2009-04-20 15:11       ` John Barham
2009-04-20 16:48         ` erik quanstrom
2009-04-19 14:27 ` Eric Van Hensbergen
2009-04-19 20:11   ` tlaronde [this message]
2009-04-20 15:48 ` ron minnich
2009-04-20 17:15   ` Wes Kussmaul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090419201151.GA3167@polynum.com \
    --to=tlaronde@polynum.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).