[PATCH v4 4/4] cpufreq: Use arch specific feedback for cpuinfo_cur_freq
Vanshidhar Konda
vanshikonda at os.amperecomputing.com
Mon Apr 15 21:23:10 PDT 2024
On Fri, Apr 05, 2024 at 02:33:19PM +0100, Beata Michalska wrote:
>Some architectures provide a way to determine an average frequency over
>a certain period of time based on available performance monitors (AMU on
>ARM or APERF/MPERf on x86). With those at hand, enroll arch_freq_get_on_cpu
>into cpuinfo_cur_freq policy sysfs attribute handler, which is expected to
>represent the current frequency of a given CPU, as obtained by the hardware.
>This is the type of feedback that counters do provide.
>
--- snip ---
While testing this patch series on AmpereOne system, I simulated CPU
frequency throttling when the system is under power or thermal
constraints.
In this scenario, based on the user guilde, I expect scaling_cur_freq
is the frequency the kernel requests from the hardware; cpuinfo_cur_freq
is the actual frequency that the hardware is able to run at during the
power or thermal constraints.
The AmpereOne system I'm testing on has the following configuration:
- Max frequency is 3000000
- Support for AMU registers
- ACPI CPPC feedback counters use PCC register space
- Fedora 39 with 6.7.5 kernel
- Fedora 39 with 6.9.0-rc3 + this patch series
With 6.7.5 kernel:
Core scaling_cur_freq cpuinfo_cur_freq
---- ---------------- ----------------
0 3000000 2593000
1 3000000 2613000
2 3000000 2625000
3 3000000 2632000
With 6.9.0-rc3 + this patch series:
Core scaling_cur_freq cpuinfo_cur_freq
---- ---------------- ----------------
0 2671875 2671875
1 2589632 2589632
2 2648437 2648437
3 2698242 2698242
In the second case we can't identify that the CPU frequency is
being throttled by the hardware. I noticed this behavior with
or without this patch.
Thanks,
Vanshi
More information about the linux-arm-kernel
mailing list