From: Andrea A. <an...@su...> - 2001-04-04 18:03:13
|
On Wed, Apr 04, 2001 at 10:49:04AM -0700, Kanoj Sarcar wrote: > Imagine that most of the program's memory is on node 1, it was scheduled > on node 2 cpu 8 momentarily (maybe because kswapd ran on node 1, other > higher priority processes took over other cpus on node 1, etc). > > Then, your patch will try to keep the process on node 2, which is not > neccessarily the best solution. Of course, as I mentioned before, if > you have a node local cache on node 2, that cache might have been warmed > enough to make scheduling on node 2 a good option. Exactly it made it a good option, and more important this heuristic can only improve performance if compared to the mainline scheduler. Infact I tried to reschedule the task back to its original node and it dropped performance, anyways I cannot say to have done an extensive research on that, I believe if we take care of some more history of the node migration we may understand it's right time to push it back to its original node but that was not obvious and I wanted a simple solution to boost the performance under CPU bound load to start with. Andrea |