![]() | ||||||||||
Messages in this thread |
* John Hawkes <hawkes@babylon.engr.sgi.com> wrote: > Some amount of code would need to be added to sched.c to deal with > unsynchronized values: scheduler_tick() remembers a local jiffies- > granularity sched_clock() in the runqueue struct, and load_balance's > can_migrate_task() uses that saved timestamp to compare against the > tested task->timestamp to determine cache-hot-or-not, rather than > using the local CPU's sched_clock() value. Also, task->timestamp > needs to be readjusted when the task migrates: this is a tough problem that wont go away. Even platforms where the per-CPU clock is supposed to be synchronized, sometimes it isnt. (this is a recurring problem on x86 SMP - so x86 will benefit from it too.) the relaxation means the effective granularity reduction of the migration decisions - but this is not a problem, migration latencies are always a high multiple of the timer irq frequency. The cycle accuracy of sched_clock() is otherwise very important for correct interactivity decisions - but this is only used locally and is thus preserved by the patch. The only area where this change can reduce the quality of interactivity estimatio is when a task oscillates very quickly between multiple CPUs and is also somehow relevant to interactivity. So i believe the generic relaxing of sched_clock() synchronization is the right thing to do. I like your patch. It adds minimal overhead and solves a hard problem - nice work! Andrew, please apply it. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | |||||||||
| Last update: 2005-03-22 12:59 [from the cache] ©2003-2008 | ||||||||||