On Tue, 2007-03-13 at 13:32 -0700, Jeremy Fitzhardinge wrote: > 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. The frequency tracking you mention is done to some extent inside the timekeeping adjustment functions, but I'm not sure it's totally accurate for non-timekeeping, and it also tracks things like interrupt latency. Tracking frequency changes where it's important to get it right shouldn't be done I think .. If you want accurate time accounting, don't use the TSC . > 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. The sched_clock interface is basically a stripped down clocksource.. I've implemented sched_clock as a clocksource in the past .. > 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. Are there other architecture which have this per-cpu clock frequency changing issue? I worked with several other architectures beyond just x86 and haven't seen this issue .. Daniel _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxx https://lists.osdl.org/mailman/listinfo/virtualization
