[runtime]wrong frequency estimation

[Stone, Joshua I]

Hi Masami,

Masami Hiramatsu wrote:
> Hi,
> 
> I found that __stp_estimate_cpufreq() in runtime/time.c returned inaccurate
> cpu frequency, especially on Xen kernel. If frequency is estimated smaller
> than true frequency, gettimeofday_*() can rewind.

Yes, virtualization can certainly be a cause of measurement error.

> Thus, I think we better use special methods for each architecture,
> e.g. cpufreq_quick_get() and cpu_khz for i386/x86-64 and local_cpu_data->
> itc_freq for ia64. If we can't use those methods, estimating frequency by
> using udeley() is the last resort.
> I attached a patch to do that.
> 
> What would you think about this idea?

If you look in _stp_init_time, the frequency from __stp_estimate_cpufreq 
is overridden by a call to cpufreq_get().  It's missing your 
alternatives of using cpu_khz or itc_freq, but you could add it there.


I've been thinking about this as part of bug #3916.  The other thing 
that I think is causing gettimeofday_*() rewinds is a broken assumption 
of mine -- get_cycles() is *not* necessarily related to the current CPU 
frequency.

On ia64, the ITC is always independent of the instruction frequency.  We 
should always be using itc_freq for our calculations.

On older Intel x86 processors, the TSC rate is equal to the processor 
clock cycle, which may be affected by SpeedStep.  Thus hooking into 
cpufreq APIs is probably necessary.

But for some Intel Xeons (family F, models 3+), Intel Core, and Intel 
Core 2, the TSC increments at a constant rate, regardless of the current 
CPU clock.  Thus it's incorrect for us to use the cpufreq APIs for these 
processors.  I'm still not sure how to determine what the actual TSC 
rate is, but the udelay estimation might have to do.

I haven't looked at what AMD processors do with TSC, or any other 
architectures with their get_cycles().  If others can chime in here, I 
would appreciate it.

Thanks,

Josh