[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <53027db5-f750-4b6f-8ac5-a849dff2524b@gmail.com>
Date: Wed, 30 Apr 2025 20:28:19 -0500
From: Russell Haley <yumpusamongus@...il.com>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>,
Linux PM <linux-pm@...r.kernel.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
Subject: Re: [PATCH v1 1/2] cpufreq: intel_pstate: Use CPPC to get scaling
factors
On 12/5/24 5:39 AM, Rafael J. Wysocki wrote:
> + * Compute the perf-to-frequency scaling factor for the given CPU if
> + * possible, unless it would be 0.
> + */
> + if (!cppc_get_perf_caps(cpu, &cppc_perf) &&
> + cppc_perf.nominal_perf && cppc_perf.nominal_freq)
> + return div_u64(cppc_perf.nominal_freq * KHZ_PER_MHZ,
> + cppc_perf.nominal_perf);
I think this exposed a firmware bug on ARL. I have a Core Ultra 265K,
and two of the E-cores report 33 for nominal_perf, while the others
report 46. They all report 3300 for nominal_freq.
The result is that the kernel thinks these two E-cores are capable of
6.5 GHz.
> grep . /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freq
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq:5400000
/sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_max_freq:5500000
/sys/devices/system/cpu/cpu2/cpufreq/cpuinfo_max_freq:5400000
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_max_freq:5400000
/sys/devices/system/cpu/cpu4/cpufreq/cpuinfo_max_freq:5400000
/sys/devices/system/cpu/cpu5/cpufreq/cpuinfo_max_freq:5400000
/sys/devices/system/cpu/cpu6/cpufreq/cpuinfo_max_freq:5400000
/sys/devices/system/cpu/cpu7/cpufreq/cpuinfo_max_freq:5500000
/sys/devices/system/cpu/cpu8/cpufreq/cpuinfo_max_freq:4600000
/sys/devices/system/cpu/cpu9/cpufreq/cpuinfo_max_freq:4600000
/sys/devices/system/cpu/cpu10/cpufreq/cpuinfo_max_freq:4600000
/sys/devices/system/cpu/cpu11/cpufreq/cpuinfo_max_freq:4600000
/sys/devices/system/cpu/cpu12/cpufreq/cpuinfo_max_freq:6500000 # wow
/sys/devices/system/cpu/cpu13/cpufreq/cpuinfo_max_freq:6500000 # amazing
/sys/devices/system/cpu/cpu14/cpufreq/cpuinfo_max_freq:4600000
/sys/devices/system/cpu/cpu15/cpufreq/cpuinfo_max_freq:4600000
/sys/devices/system/cpu/cpu16/cpufreq/cpuinfo_max_freq:4600000
/sys/devices/system/cpu/cpu17/cpufreq/cpuinfo_max_freq:4600000
/sys/devices/system/cpu/cpu18/cpufreq/cpuinfo_max_freq:4600000
/sys/devices/system/cpu/cpu19/cpufreq/cpuinfo_max_freq:4600000
Hopefully you have the ear of someone on the firmware team so that a
ticket can be created for this.
In Phoronix discussion, users have reported seeing this on both ASRock
and MSI motherboards:
https://www.phoronix.com/forums/forum/hardware/processors-memory/1541981-intel-core-ultra-9-285k-arrow-lake-performance-on-linux-has-improved-a-lot-since-launch?p=1543676#post1543676
----------
Also, this may be related... I can't set scaling_max_freq to odd
multiples of 100 MHz, only even. Checking with:
x86_energy_perf_policy &| grep -i req
reveals that some values of max are being skipped. Setting manually with
x86_energy_perf_policy --cpu 0-7 --hwp-max 76
allows the odd multiples to be accessed. Integer division issue somewhere?
Powered by blists - more mailing lists