From: george a. <ge...@mv...> - 2001-02-13 02:39:41
|
Jun Nakajima wrote: > > I agree. I think the scope of the values returned by goodness() is not > clear even with the original scheduler - it's not local or global > either, because of PROC_CHANGE_PENALTY, which should be > platform-dependent. > > So I don't think we need to stick to the current scheduler semantics for > non-realtime tasks, especially when supporting larger SMP machines, > including NUMA. > > Besides the cpu_allowed mask, one thing I would like to add is to check > if its cache is still warm or not there, when stealing a task from a > remote CPU. We don't want to migrate such a task with warm cache even if > it has a high na_goodness value. One of easy and effective ways is to > maintain the last time (jiffies) when the task was scheduled. If the > time is larger than some tunable/platform-specific value, then we might > want to migrate the task, otherwise find another one. I bet this would > cause significant scheduling behavior changes. Such a test might be done on run list insertion also. I.e. why favor the last cpu if all the tasks data has long since been flushed from that cpu's cache? Then you might keep a count of the aggregate number of "ticks" in each cpu's run list and add a task with stale cache history to the list with the least aggregate count. George > > Hubertus Franke wrote: ~snip |