Ingo Molnar wrote on Friday, November 17, 2006 11:21 AM > * Mike Galbraith <[EMAIL PROTECTED]> wrote: > > > One way to improve granularity, and eliminate the possibility of > > p->last_run being > rq->timestamp_tast_tick, and thereby short > > circuiting the evaluation of cache_hot_time, is to cache the last > > return of sched_clock() at both tick and sched times, and use that > > value as our reference instead of the absolute time of the tick. It > > won't totally eliminate skew, but it moves the reference point closer > > to the current time on the remote cpu. > > > > Looking for a good place to do this, I chose update_cpu_clock(). > > looks good to me - thus we will update the timestamp not only in the > timer tick, but also upon every context-switch (when we acquire > sched_clock() value anyway). Lets try this in -mm?
Certainly gets my vote. For my particular workload environment, there are enough schedule activity on the remote CPU and in theory it should make time calculation a lot better than what it is now. I will run a couple of experiment to verify. Acked-by: Ken Chen <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
