lkml.org 
[lkml]   [2000]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Help in DSM design

> Not just that. On SMP, and even more on NUMA, you only get scalable
> performance by going out of your way to avoid unnecessary sharing of
> data. It's just not transparent. And when you _do_ want to pass data
> from X to Y, you only want to do it once, which requires extra
> synchronisation to make sure that the receiver of the data doesn't start
> peeking at the data structures until the data is known to arrive.
>
> With message passing, that synchronisation is implicit. With shared
> memory, about all you can do is spin waiting for the data to arrive,
> unless you add a separate synchronisation mechanism somewhere to do
> locking outside the shared memory channel.
>
> It's not just granularity. The synchronisation hit is bad, on _all_
> forms of DSM up to and including SMP. (The latest Linux development
> kernel includes "big reader" locks which allow a read-mostly data
> structure to be locked on each CPU separately with no inter-CPU memory
> traffic at all, simply because even on such tightly coupled systems the
> cost of passing even one cache line of shared memory traffic between
> CPUs is too high.)

The argument here is essentially that shared-memory as a programming
model doesn't scale, as well as message passing can.. DSM just makes
it more evident.
But the lure of the easier programming model is substantial; and
applications come in all flavors from will scale on anything, to
won't scale on shared-memory but do OK on message-passing, to won't
scale on message-passing either - it boils down to the extent of
state sharing and synchronization inherent in the application.
There's been considerable research in shared-memory protocols which
have mechanisms to (try to) bring the communcation/synchronization
down to the 'implicit in the application' minimum, as a msg-passing
program would. They seem to work for some applications but I wouldn't
say are general enough to be practical.
But they mostly are explicit communication primitives within the
context of coherence protocols and consistency mechanisms. I think
one could reap most of the 'ease of programming' benefits of
shared-memory programming by just having a global-address space and
build 'put'/'get' kind of primitives to communicate explicitly on
the top - kinda like msg-passing.

:a

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:56    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site