Dirk: I understand that it does not say about current frequency (it does not take into account such factors as c-states and turbo boost for instance). Yet, if it does say about a current p-state of a core, then it is a valid and useful piece of information. For instance, while testing cpufrequtils on Intel i7, Intel i5 and Core 2 duo cpus, I observed that while the requested frequency (policy->cur) for different cores may be different, the frequency reported on the basis of the current p-state (read from MSR_IA32_PERF_STATUS) is all the time the same for all the cores. This suggests that all the cores are in the same frequency domain (hardware coordinated). Viresh, why is it ill-conceived? As I said above, I think the information concerning current p-state can be useful - as long as it is accurate. Do you have any premises to say that it is not accurate in terms of the current p-state of a core? Best regards, Magdalena 2014-11-26 16:29 GMT+01:00 Dirk Brandewie <dirk.brandewie@xxxxxxxxx>: > On 11/25/2014 10:07 PM, Viresh Kumar wrote: >> >> 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 ? > > > Not really. This issue is one of the reasons that intel_pstate returns a > measured/effective frequency. There is no way that I know of to get the > instantaneous frequency that the core is running at in the presence of > hardware coordination and idle. The best you can do is measure the > effective > frequency over a sample time. This is what turbostat and intel_pstate > report. > > --Dirk > >> > -- 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
