Messages in this thread | | | From | (Larry McVoy) | Subject | Re: Remote fork() and Parallel programming | Date | 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
| |