On Monday 02 April 2007 08:47, Jeremy Fitzhardinge wrote: > Andi Kleen wrote: > > I think it would be much cleaner if you didn't implement your own > > sched_clock, > > but you adjust ns_base/last_tsc to account for your lost cycles. > > This could be done cleanly by adding a new function to sched-clock.c > > Possibly such a function could be used by other parts of the kernel > > in the future too. > > > > Cleaner how? This seems pretty to me. Xen can return a > clock measuring unstolen nanoseconds,
Do you also get a clock for stolen nanoseconds? > which maps directly to the > sched_clock interface, doesn't need any of the existing sched_clock > code. I suppose I could map the Xen interface onto some abstract > "cycles" notion and hook it into the tsc machinery, but it seems like it > would be a forced fit. In general, my approach has been to choose the > higher-level interface over a lower-level one, all other things being equal. No need for cycles, you could just subtract the stolen ns if you can get those. -Andi - 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/
