linux-kernel - Re: [PATCH v1 1/2] cpufreq: intel_pstate: Use CPPC to get scaling factors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [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?