Re: Remote fork() and Parallel programming

David Lang (dlang@diginsite.com)
Mon, 15 Jun 1998 21:05:59 -0700 (PDT)


-----BEGIN PGP SIGNED MESSAGE-----

if the system is close to tranparent, it may be a combination of programs.
but even with your types of programs it could be adventagious to switch

Example
machines 1,2,3,4 are all running your app and are perfectly balanced for 10 min.
then a process on one machine wakes up and starts running (spawning multiple
copys for speed like sendmail does). now tha machines are not balanced and it
may be adventagious to move the distributed app (or move some of the spawned
processes of the new app) to another machine on the cluster.

David Lang

On Mon, 15 Jun 1998, Larry McVoy wrote:

> Date: Mon, 15 Jun 1998 08:39:26 -0700
> From: Larry McVoy <lm@bitmover.com>
> To: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Cc: linux-kernel@vger.rutgers.edu
> Subject: Re: Remote fork() and Parallel programming
>
> : > Process migration on SMP is a horrible idea. As I have mentioned
> : > repeatedly, read any one of the dozens of papers on a cache affinity.
> : > They all show how in almost all cases, the absolute worst thing you
> : > could do for performance is to reschedule a process on another CPU.
> :
> : Its a matter of time scales. Leaving a cpu idle for 60 seconds with two
> : jobs on another CPU is bad on a conventional SMP box - by then cache
> : affinity is noise in the efficiency graph.
>
> Quick - name me one parallel computation that would leave a CPU idle
> for 60 seconds while the other ones are busy on an SMP. The point?
> All the parallel computations I've seen statically load balance at
> initialization time and then never move.
>
> I agree that there are other types of parallel loads, but they
> tend to be more of the time sharing sort. I don't think anyone
> is suggesting that migrating vi or sendmail is a good idea. Right?
>
> : The same is going to be true for dynamic load balancing - if you are talking
> : about this sort of balancing on large enough timescales it will make sense
> : - true it may be every 30 minutes and you may try to do minimal movement
>
> So explain to me what application will be nicely balanced for 30
> minutes and then need to be moved to be balanced? How would one go
> about deisgning such an application?
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQEVAwUBNYXvKT7msCGEppcbAQH2FQf9HUHgexMOd675vLHm2bbCJXDqoHIrivl1
FK3CxkY7gCArkB00pcqcxd5+ZCtK0XO/kjq2z7c39zyapNRMK6qubZbIzUDebVSH
+bY9FC4zLLf6LVGuOH/qEiEVF+FkREPuo7Oi4QA6pIDJrmAlDVUu2Azu5p00y16y
2rvP1hPcuEBqLIbWdooCTxi8ZZo+9cKkFH1ZHBiBDyj4c3XgBQ6OAf9T+fqEdRLR
d67Aa9kHIqeXV7jSC2qySWh3jUxqmtHq7pkxBvw4taNvrOuz/crCXAmd+VMN0J7d
D5lRPfpBT9MEe1xEya3JYYGtGR7V2a5KzS5qh5rIXPgMeBwxtJxJQA==
=OiRn
-----END PGP SIGNATURE-----

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