"Theodore Y. Ts'o" <tytso@MIT.EDU> wrote:
> >It's not the bandwidth that's the issue, it's the latency. Bandwidth is
> >easy. Latency is hard. DSM systems /all/ die because of latency issues.
>
> The main argument of anti-DSM people has always been the band-width (that
> message passing can better use the bandwidth because the programmer has
> total control over the transfers and can tune the program's behaviour), but
> fortunately that is no longer important.
>
>Would you like to say more about that? I would think that this is very
>important, and not being able to handle this case well would result in
>really bad performance.
Message passing systems require the programmer to explicitly transfer data
to/from other computers. The programmer knows the application's data needs,
so he can bring only the needed data, and at the time it is actually needed.
This results in efficient bandwith usage.
The kind of DSM I am talking about (transparent operation, as in DIPC), does
not use explicit commands from the application to do its work. CPU's memory
managemnet unit informs the DSM manager that a process is refering to some
part of the memory that is not present, or is trying to write to a read-only
address. That is all the information a DSM manager gets. It then works to
make it possible for the application to perform its intended action, possibly
by transfering the needed data from another computer. In DIPC's case, each
transfer involves a multiple of 4K bytes.
The performance will degarde if two or more processes try repeatedly to
write to the same (or nearby) memory locations, at the same time. reads are
not that much a problem, because the data can be replicated for each process.
The point is that the programmer knows more about the application's
behaviour than a DSM manager. He can do more work to get better performance.
My argument is that in most situations ease of programming is preferable,
especially because the bandwith is increasing (so sending more data than
absolutly necessary is not a big problem).
The DSM programmer just has to obey some very simple and commonsense rules
(like not doing busy waiting, which is bad in all cases) to get accepatble
performance. This is by far easier than message passing, which is not based
on the idea of shared memory for data transfer (the case in normal
programming).
>If the programmer doesn't know which shared memory is local and which
>shared memory is distributed across systems, the resulting performance
>characters could be quite ugly.
With current technology, yes. It depends on the design of the DSM. Some
prefer the whole address space to be distributed (ideally a good idea).
A bit more conservative systems are those that let the programmer know which
addresses are distributed and which are not. An example is DIPC
( http://wallybox.cei.net/dipc ) that distributes only System V's shared
memories.
-Kamran Karimi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu