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    [W:0.023 / U:93.052 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site