[lkml]   [2000]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:56    [W:0.023 / U:119.984 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site