[PATCH 0/3] cpufreq: Avoid fallback values in cpuinfo_avg_freq

From: Chuyi Zhou

Date: Wed Sep 16 2026 - 10:51:58 EST


Introduction
============

cpuinfo_avg_freq is intended to expose an average operating frequency
derived from hardware feedback over a short time interval. On x86, it
can instead return a policy value or cpu_khz when no usable sample is
available. Userspace cannot distinguish that fallback from a measurement.

Provide a separate hardware feedback getter for cpuinfo_avg_freq so that
missing measurements are reported as errors. Keep the existing frequency
reporting behavior of scaling_cur_freq and /proc/cpuinfo.

Background
==========

The x86 frequency reporting path uses APERF/MPERF samples collected by
the scheduler tick. Reading the cached samples avoids sending IPIs to
wake idle CPUs or interrupt isolated CPUs. If a sample is older than
approximately 20 ms or has a zero MPERF delta, arch_freq_get_on_cpu()
falls back to cpufreq_quick_get(), and then to cpu_khz if that returns
zero.

Commit fbb4a4759b54 ("cpufreq: Introduce an optional cpuinfo_avg_freq sysfs
entry") reused arch_freq_get_on_cpu() for cpuinfo_avg_freq. This exposed
the x86 fallback through an interface intended to report the frequency
at which the hardware actually ran.

For example, the active amd-pstate-epp driver sets policy->cur to
policy->min, including under the performance policy. When a sample
expires, cpuinfo_avg_freq can therefore switch from a measured frequency
to the policy minimum. Monitoring software can interpret this as a
frequency drop even though no measurement supports that conclusion.

Commit 9e4cb21f2940 ("cpufreq: intel_pstate: Adjust policy->cur in active
mode to policy") changed the Intel performance-policy fallback to the
requested frequency. That value cannot establish that the hardware
reached the requested frequency, so the same ambiguity remains.

Missing samples are not limited to idle CPUs. The scheduler skips
frequency sampling on CPUs excluded from HK_TYPE_KERNEL_NOISE
housekeeping. A nohz_full CPU can lack a usable sample while running a
busy workload. Conversely, a CPU that has just entered idle can still
have a valid cached sample.

Changes
=======

Introduce arch_freq_get_avg() to separate hardware feedback from the
compatibility fallback. Use it for both cpuinfo_avg_freq reads and the
attribute's support probe. On x86, the behavior changes as follows:

Condition Before After
--------- ------ -----
Usable sample Measured frequency Measured frequency
Expired sample Fallback frequency EAGAIN
Zero MPERF delta Fallback frequency EAGAIN
No APERF/MPERF support Fallback frequency Attribute absent

ARM64 reuses its existing AMU implementation without changing its behavior.

Chuyi Zhou (3):
x86/aperfmperf: Separate hardware feedback from fallback reporting
cpufreq: Use hardware feedback for cpuinfo_avg_freq
x86/aperfmperf: Clean up includes after removing IPI sampling

Documentation/admin-guide/pm/cpufreq.rst | 11 ++++++--
arch/arm64/kernel/topology.c | 7 ++++-
arch/x86/kernel/cpu/aperfmperf.c | 33 +++++++++++++++++-------
drivers/cpufreq/cpufreq.c | 19 ++++++++++++--
include/linux/cpufreq.h | 1 +
5 files changed, 56 insertions(+), 15 deletions(-)


base-commit: e81ee06308379a5f2ededf997bcf17551bce5db7
--
2.20.1