On 25 November 2014 at 22:51, Magdalena Dobosz <maj.dobosz@xxxxxxxxx> wrote: > Hi, > I was analyzing the code and behaviour of cpufrequtils (kernel 3.13). > I noticed that the value reported by cpufreq-info as the frequency > "asserted by call to hardware" (exported to sysfs as > "cpuinfo_cur_freq") is always the same as the value reported as the > frequency requested by a governor (exported to sysfs as "freq", stored > in policy->cur). > It was not the case for kernel 3.2 (these two values tend to differ). > > I found a reason: while using acpi-cpufreq driver, the value reported > as hardware frequency is retrieved using get_cur_freq_on_cpu function > (defined in acpi-cpufreq). Now, in kernel version 3.2 this function > reads a value from MSR_IA32_PERF_STATUS, while in kernel 3.13 it reads > MSR_IA32_PERF_CTL. > It is a result of the patch shown below: > https://lists.ubuntu.com/archives/kernel-team/2013-June/029493.html > > It looks like a bug for me - we take a requested frequency (control > register) and we report it as "cpuinfo_cur_freq - Current frequency of > the CPU as obtained from the hardware, in KHz. This is the frequency > the CPU actually runs at." (as desribed in cpufrequtils documentation: > https://www.kernel.org/doc/Documentation/cpu-freq/user-guide.txt";. I > believe we should read status register (MSR_IA32_PERF_STATUS) instead. Fixed list and cc'd few more. This is what Len Brown said to that patch: Ack -- MSR_IA32_PERF_STATUS is ill-conceived. It is un-reliable by its very definition. Any code that depends on it should be questioned... @Dirk: Can you help ? -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
