Port-amd64 archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Wrong CPU frequencies reported by cpu_get_tsc_freq() ?



On Sun, Jul 26, 2015 at 05:25:19PM -0700, Dennis Ferguson wrote:
> 
> I'm pretty sure it is telling you that i8254_delay() becomes grossly
> inaccurate when all but one of the CPUs in the system sit in the tight
> loop in there simultaneously reading the same timer register over and over.
> On my system, where the TSC increments at a constant 3500 MHz on all
> CPUs, I have right now:

Thanks. That makes sense ...

> The more interesting question why it bothers making per-cpu measurements
> at all?  The kernel uses the TSC as a clock source only when it thinks
> that the TSC's frequency is constant with time and its rate of advance is
> identical on all processors. The system that produced the above list
> of frequencies is also using the TSC as its system clock, so clearly
> the system believes the TSC frequency is identical for all CPUs and
> hence that most of the frequencies it went to the trouble of measuring
> above are bogus. Nothing I can find uses any of those numbers other than
> the first.
> 
> At one point I thought about removing the calls to cpu_get_tsc_freq()
> in cpu_hatch(), but since they were explicitly added in there in
> revision 1.7 of sys/arch/x86/x86/cpu.c it seems like there must have
> been some purpose for the addition.  Since the per-cpu frequency
> measurements couldn't have been the reason I guessed the 100 ms
> delay that is a side effect of the measurement might be doing something
> useful, and removing the calls might require figuring out what that is.

Not sure what to do either.

My original idea was to check that CPU frequency reported in
/proc/cpuinfo was not the fixed TSC but rather the real frequency the
processor where set to, just like Linux does.

By example, on an AMD machine with an "AMD Opteron(tm) Processor 6128"
processor that can handle multiple frequency values with powernow :

njoly@lanfeust [~]> sysctl machdep.powernow.frequency
machdep.powernow.frequency.target = 800
machdep.powernow.frequency.current = 800
machdep.powernow.frequency.available = 2000 1500 1200 1000 800

The /proc/cpuinfo reported value should match the one from .current.
Likewise for machdep.est.* for Intel processors, and possibly others.

While i can add a call to cpu_get_tsc_freq() to procfs_getonecpu()
this does not seems to be the right approach ... procfs should only
fetch the current frequency, not compute it.

-- 
Nicolas Joly

Computing Group
Biology IT Center
Institut Pasteur, Paris.


Home | Main Index | Thread Index | Old Index