Forgive me if this is an old idea discredited long ago...
The choice to leave a process idle rather than move it to a new
processor where its cache would be cold is a gamble. If the
desired CPU becomes idle soon enough and the process has enough
useful data stored in its cache the gamble can pay off. After
some amount of time it would be necessary to admit defeat and
schedule to the cold processor.
A different, more conservative, gamble would be to schedule on the
cold processor right away but reconsider when the previously
favored processor becomes free. If the process has been on its
new processor a very brief period of time it might be worth
sending it back. If the time is longer it should be left alone
and its new home regarded as preferred.
It may not be worth the complexity or the double bounce between
CPUs but if it is common for processes to bounce as a result of very
brief interruptions it might be a win. How many cache misses
does it take to compare with the cost of moving a process?
Mark
>That's not the situation --- the problem is what to do if you have two
>foreground tasks running on two cpus, and one sleeps. You don't have
>the option of scheduling the background task on the other CPU at this
>point --- at least, not without forcing a CPU switch on the other
>foreground task, which rather defeats the purpose of the exercise. So
>you either have to run it on the local CPU, which may not have been the
>last one to run the background task, or you have to just leave the local
>CPU idle in the hope that the background task will soon be able to get a
>shot at its "home" CPU.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Feb 07 2000 - 21:00:07 EST