On Wednesday, November 26, 2014 09:41:02 PM Magdalena Dobosz wrote: > 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, You can't trust it, though, because the moment you've read the value and are now going to use it, it may be already stale. > 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). Which usually is the case for (current) desktop processors, but may not be the case for server ones. > 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? Please see above. Kind regards, Rafael > 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 > > > >> > > -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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
