Re: Remote fork() and Parallel programming

Larry McVoy (lm@bitmover.com)
Mon, 15 Jun 1998 08:48:03 -0700


: >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

Not true at all, go back and look through virtually 100% of the so called
anti-DSM papers, and a great deal of the pro-DSM papers, and you'll see
that latency is the issue. The most recent of these is Andrew Erlichson's
PhD thesis that did a DSM based on HIPPI (100MByte/sec) on SGI machines.

: >It is my claim that 100% of the DSM systems cn be proven to be a bad idea
: >if the designers had sat down and measured the local versus remote memory
: >latency. Numbers talk. And DSM numbers just show you that it isn't a
: >very useful idea.
:
: Wrong argument. One encounters the latency problem _each_ time one transfers
: data over a network, no matter what the programmer does to initiate this
: transfer. The DSM and message passing argument is more about programming
: interfaces. The latency will not decrease if the programmer uses messages (or
: _any_ other method) to transfer 4KB of data to another computer.

OK, so how about this one: process A spins on memory, process B sets
the memory, process B spins on same memory, process A sets it ....

Every one of those handshakes is a 4K page in DSM, right? It pretty
much has to be if 4K is what your system thinks a page is and you
are mapping this stuff into your address space.

So explain to me how the latency of a 4K transfer is going to be lower
or the same as a 4 byte transfer (which is all that is required to do
the same thing in message passing)?

And if you want to just ignore this, it would be nice if you were to
explain to our audience exactly how common this sort of operation is
in those shared memory applications that you want to support without
modification (hint: it's extremely common, every spin lock, mutex,
semaphore does it).

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu