Re: [patch 17/17] Add a sched_clock paravirt_op

[Jeremy Fitzhardinge <jeremy@goop.org>]

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