Re: Remote fork() and Parallel programming

mshar@vax.ipm.ac.ir
Tue, 16 Jun 1998 11:21:10 +0330


Hi,

Andrej Presern <andrejp@luz.fe.uni-lj.si> wrote:

>You've clearly pointed out that in order to be efficient (or at least
>work) in a cluster, applications WILL have to be modified. So what's
>about the 'old apps will benefit' argument? [...]

We are not living in a perfect world, but there are modifications, and then
there are modifications. It is a fact that currently network operations are
more costly than local operations, so the system's decision to distribute an
application's code or data to other computers can have a negative effect. I
hope one day this will not be an issue any more. The _programming_model_ in
most current distributed systems is very different from normal programming.
Adding _one_ statement (a hint) to make a program able to function
distributedly is not much source code modification to expect, especially
because we are doing it so that older programs that were not "designed" to
work in a distributed environment can continue to do work.

We are retaining the familiar _programming_model_. Not only developing new
distributed software becomes much eaiser, but _if_ the sources to an old
application are available (not always true), then modifying it to work in a
distributed environment will be rather easy.

>> If the user sees a drop in performance, after allowing process migration in
>> one run of the program (an error in the migration-decision algorithm), then
>> it will allow the program to run only locally the next time. This works
>> because most programs are executed many times.
>
>Who says the use of resources won't be radically different the next time
>the app is run?

In my experience, most programs are repeatedly run to solve similar problems
while using nearly the same kind and amount of resources.

>> I thought this is too obvious to write.
>
>A page in memory looks like this:
>[data, data, data, ...]
>
>When the page is migrated to another host, it gets to look like this:
>[envelope,
> [data, data, data, ...]
>]
>
>The page is put into an envelope that carries it to the new destination.
>I'd say that such a page in migration is not really a 'page', but a
>message whose data is the page. Obvious enough?

Thanks for explaining this to me (DIPC's sources are a good example of
how such things work in practice), but you wrote all this just to say that
DSM is actually implemented on top of a messaging system?? Isn't this obvious
that the CPUs in two conventional computers can not have direct access to
each other's memory, and that "simulating" DSM will need some form of message
passing (maybe in the form of TCP/IP packets)??

The difference is that DSM uses the messages transparently. Busy waiting
by the progrgrammer may cause many messages to be transferred, so what?

Again, the DSM vs message passing debate is about programming interfaces.
DSM works at a higher level of abstraction. It is unfortunate that due to
some practical limitations, employing the exact same methods used in single
computers may not work well. But we can get very close.

-Kamran Karimi

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