> : > 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.
Realworld system load.. (there 1 second flat)..
Think users a b c and d start up apps.. Suppose apps dont migrate.
cpu1 cpu2
a,b c,d
Then users a and b's apps finish (the just ran ls) while c and d are
running long standing computation..
The cache hit is tiny compaired to the increase in performance.
> 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?
We just refering to SMP.. But, still.. On a system with 10000 users why
not migrate vi.. You advocated remote exec..
> : 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?
You are thinking single purpose computers.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu