Messages in this thread | | | Subject | Re: Process Migration on Linux - Impossible? | From | Rick Wheeler <> | Date | Tue, 30 Sep 1997 21:03:53 -0400 |
| |
I think that the SMP comparison is irrelevent to the generic process migration case. Clearly, in an SMP box, if you have the resources needed to keep a job in memory and run it, running it on the same CPU is probably a win.
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. >
| |