Messages in this thread | | | Date | Tue, 07 Mar 2000 10:28:21 -0800 | From | Aman Singla <> | Subject | Re: 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/
| |