In a cluster of workstations, the decision to migrate a process is
done only when you (that is the migration algorithm) determines that
the process migration costs are outweighed by the improvement gained
by running on a relatively lightly loaded box. Migration allows you
to dynamically adjust to changing load and take advantage of that.
If you would like to read about actual measurements done on a real
system, try:
A. Barak, R. Wheeler, MOSIX: An Integrated Multiprocessor UNIX,
Proceedings of 1989 Winter USENIX Technical Conference, San Diego,
February, 1989.
We present several examples, doing a parallel "make" on a MOSIX
system was a joy.
Again, I would like to stress that migration is not a lightweight
operation, but that does not mean that you cannot have significant
gains for certains jobs. As an OS hacker who did my part to implement
dynamic process migration in MOSIX (and then went on to work on the
CM5 operating system), I am also aware that the commercial success of
intersting and innovative systems is not a given :-)
ric
In message <199709302358.QAA09705@linux.cobaltmicro.com>you write:
> : I don't know that migration impacts performance.
>
> In an SMP it totally screws up your cache utilization. Process migration
> across machines is just a larger version of rescheduling on another CPU
> in an SMP. There are literally hundreds of papers on cache affinity and
> schedulers. They show that it is almost always a bad idea to move the
> process, something which is intuitively obvious to hardware guys who have
> memorized cache miss costs and know how long it takes to refill a cache.
> Here's an example: suppose you have a 10 millisecond time slice, a 4MB
> cache w/ only your data in it, a 32 byte cache line, and 500ns cache
> miss penalty. If you move the process, it will take 131,072 cache misses
> to fill up that cache. That is 65,536 usecs or about 7 time slices.
> if your scheduler moves you ever time slice, you lose big time, you'll
> never get any work done out of the cache.
>
> The math for process migration across machine boundries is similar, except
> it frequently gets worse - the cost of moving is in 100s of milliseconds
> and the cache is a file system page cache with even longer refill times.
>