Yes, you could imagine adding it as a clocksource variant, by allowing a
clocksource to set a particular timebase:
enum clocksource_timebase {
CLOCK_TIMEBASE_REALTIME,
CLOCK_TIMEBASE_CPU_WORK,
...
};
struct clocksource {
enum clocksource_timebase timebase;
...
}
Most of the existing clocksource infrastructure would only operate on
CLOCK_TIMEBASE_REALTIME clocksources, so I'm not sure how much overlap
there would be here. In the case of dealing with cpufreq, there's a
certain appeal to manipulating the shift/mult parameters to reflect the
fractional speed of a cpu as it changes.
sched_clock would definitely be the interface which exposes all this
stuff to the rest of the kernel. After all, its basically a very simple
interface, though the backend implementation details may not be.
We currently have a sched_clock interface in paravirt_ops to deal with
the hypervisor aspect. It only occurred to me this morning that cpufreq
presents exactly the same problem to the rest of the kernel, and so
there's room for a more general solution.
J
-
