Re: [PATCH v2] x86: Calculate MHz using APERF/MPERF for cpuinfo and scaling_cur_freq

[Len Brown]

> I have a minor ABI concern with this patch.  It seems that there is much more
> variance in the output of "cpu MHz" with this patch, and I think that
> needs to be noted in the changelog.
>
> ISTR having a conversation a while ago (with you Len?  with Srinivas?)
> where I mentioned that "cpu MHz" used to just reflect the "marketing"
> frequency of the processors on the system.  Is it worth going back to
> that static state, and leaving the calculation for the current frequency to
> userspace programs like turbostat, cpupower, etc.?
>
> FWIW: I *regularly* get bugzillas filed from people who do not understand
> that "cpu MHz" shows the current frequency of the core.  I've often
> thought it would be easier to make that value static ...

I am fine with always printing static cpu_khz in /proc/cpuinfo on all machines.

If it were up to me, I would not have allowed the cpufreq sub-system
to start messing with this.

But it did, and I figured the genie was out of the bottle.
Assuming I'd never be able to get the community to agree to stuff the
genie back in the bottle,
I figured that this file should show a value that actually means something,
and isn't completely different depending on the choice of cpufreq
driver being used on that system.  Indeed, your comment on variability
is right on the money, this solution is less "variable" than some drivers,
such as intel_pstate, and more variable than others, such as acpi-cpufreq.
Neither of those drivers return a value that is particularly meaningful.
This solution at least, has a semantic definition.

Len Brown, Intel Open Source Technology Center