On Wed, 15 Nov 2017, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <rafael.j.wyso...@intel.com> > > After commit 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get() > for /proc/cpuinfo "cpu MHz"") the "cpu MHz" number in /proc/cpuinfo > on x86 can be either the nominal CPU frequency (which is constant) > or the frequency most recently requested by a scaling governor in > cpufreq, depending on the cpufreq configuration. That is somewhat > inconsistent and is different from what it was before 4.13, so in > order to restore the previous behavior, make it report the current > CPU frequency like the scaling_cur_freq sysfs file in cpufreq. > > To that end, modify the /proc/cpuinfo implementation on x86 to use > aperfmperf_snapshot_khz() to snapshot the APERF and MPERF feedback > registers, if available, and use their values to compute the CPU > frequency to be reported as "cpu MHz". > > However, do that carefully enough to avoid accumulating delays that > lead to unacceptable access times for /proc/cpuinfo on systems with > many CPUs. Run aperfmperf_snapshot_khz() once on all CPUs > asynchronously at the /proc/cpuinfo open time, add a single delay > upfront (if necessary) at that point and simply compute the current > frequency while running show_cpuinfo() for each individual CPU. > > Also, to avoid slowing down /proc/cpuinfo accesses too much, reduce > the default delay between consecutive APERF and MPERF reads to 10 ms, > which should be sufficient to get large enough numbers for the > frequency computation in all cases. > > Fixes: 890da9cf0983 (Revert "x86: do not use cpufreq_quick_get() for > /proc/cpuinfo "cpu MHz"") > Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Acked-by: Thomas Gleixner <t...@linutronix.de> Tested-by: Thomas Gleixner <t...@linutronix.de>
