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 straightforward to me. Xen can return a
clock measuring unstolen 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.
The only reason I hoisted the cycles_2_ns stuff was for vmi. It returns
a tsc-like cycles interface, and so it can make use of the existing
cycles_2_ns code (though I don't think a changing timebase is an issue).
J
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
