Re: Remote fork() and Parallel programming

Alan Cox (alan@lxorguk.ukuu.org.uk)
Mon, 15 Jun 1998 17:57:08 +0100 (BST)


> : Ray tracing, when one CPU gets a very simple block of rays.
>
> OK, but finish the argument. If all the other CPUs are busy doing their
> larger blocks of rays, how does migration help me in this case?

You have more blocks than processors. What happens nowdays is people right
their own scheduler for the job. PVM povray simply despatches more blocks

> : Because people use them for customised specific jobs, partly because thats
> : the most efficient way to do it in CPU terms (and Im not arguing that issue
> : - DSM is less efficient)
>
> So are you just giving up on the efficiency issue? It's OK to throw
> performance away because you are using DSM?

Which is going to cost more - a clean DSM environment thats easy to get
things running in or a hard to use but slightly more efficient MPI interface
(and if we are going to argue efficiency you can stick PVM somewere damp
and hit the flush).

What matters is that the minimal amount of support and no more is in the kernel
and that the 'user friendly' layers are in the libraries where they impact
nobody else.

Cluster costs are diving, programmer time is not.

I've read all the DIPC code (have you ?) and I think its close to meeting
that stated aim.

> Sure, for that sort of application, migration is great. As long as the
> process of "quietly sliding off" doesn't involve 300MB of data that the
> fortran job was chewing on.

Yes. MOSIX did its migration based on the amount of data transfer being
caused. For 300Mb of data it may be worth thinking hard about paging
data from the source to destination (probably not in 4K chunks but in
some chunking size)

Alan

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