[Deepin Kernel SIG] [Intel] Intel pstate backport from v6.11 #540
Conversation
commit 37b6ddb upstream. Setting global turbo flag based on CPU 0 P-state limits is problematic as it limits max P-state request on every CPU on the system just based on its P-state limits. There are two cases in which global.turbo_disabled flag is set: - When the MSR_IA32_MISC_ENABLE_TURBO_DISABLE bit is set to 1 in the MSR MSR_IA32_MISC_ENABLE. This bit can be only changed by the system BIOS before power up. - When the max non turbo P-state is same as max turbo P-state for CPU 0. The second check is not a valid to decide global turbo state based on the CPU 0. CPU 0 max turbo P-state can be same as max non turbo P-state, but for other CPUs this may not be true. There is no guarantee that max P-state limits are same for every CPU. This is possible that during fusing max P-state for a CPU is constrained. Also with the Intel Speed Select performance profile, CPU 0 may not be present in all profiles. In this case the max non turbo and turbo P-state can be set to the lowest possible P-state by the hardware when switched to such profile. Since max non turbo and turbo P-state is same, global.turbo_disabled flag will be set. Once global.turbo_disabled is set, any scaling max and min frequency update for any CPU will result in its max P-state constrained to the max non turbo P-state. Hence remove the check of max non turbo P-state equal to max turbo P-state of CPU 0 to set global turbo disabled flag. Intel-SIG: commit 37b6ddb cpufreq: intel_pstate: Revise global turbo disable check. Backport intel_pstate driver update for 6.6 Signed-off-by: Srinivas Pandruvada <[email protected]> [ rjw: Subject edit ] Signed-off-by: Rafael J. Wysocki <[email protected]> [ Yingbao Jia: amend commit log ] Signed-off-by: Yingbao Jia <[email protected]>
…ce EPP commit 2719675 upstream. The platform firmware can provide a balance performance EPP value by enabling HWP and programming the EPP to the desired value. However, currently this only takes effect for processors listed in intel_epp_balance_perf[], so in order to enable a new processor model to utilize this mechanism, that table needs to be updated. It arguably should not be necessary to modify the kernel to work properly with every new generation of processors, though, and distributions that don't always ship the most recent kernels should be able to run reasonably well on new hardware without code changes. For this reason, move the check to avoid updating the EPP when the balance performance EPP is unmodified from the power-up default of 0x80 after the check that allows the firmware-provided balance performance EPP value to be retrieved. This will cause the code to always look for the firmware- provided value before consulting intel_epp_balance_perf[] and the handling of new hardware will not depend on whether or not that thable has been updated yet. Intel-SIG: commit 2719675 cpufreq: intel_pstate: Prioritize firmware-provided balance performance EPP. Backport intel_pstate driver update for 6.6 from 6.11 Signed-off-by: Srinivas Pandruvada <[email protected]> [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> [ Yingbao Jia: amend commit log ] Signed-off-by: Yingbao Jia <[email protected]>
commit e950131 upstream. Users may disable HWP in firmware, in which case intel_pstate will give up unless the CPU model is explicitly supported. See also the following past commits: - commit df51f28 ("cpufreq: intel_pstate: Add Sapphire Rapids support in no-HWP mode") - commit d8de7a4 ("cpufreq: intel_pstate: Add Skylake servers support") - commit 706c532 ("cpufreq: intel_pstate: Add Cometlake support in no-HWP mode") - commit fbdc21e ("cpufreq: intel_pstate: Add Icelake servers support in no-HWP mode") - commit 71bb5c8 ("cpufreq: intel_pstate: Add Tigerlake support in no-HWP mode") Intel-SIG: commit e950131 cpufreq: intel_pstate: Add Emerald Rapids support in no-HWP mode. Backport intel_pstate driver update for 6.6 from 6.11 Signed-off-by: Zhenguo Yao <[email protected]> Acked-by: Srinivas Pandruvada <[email protected]> [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <[email protected]> [ Yingbao Jia: amend commit log ] Signed-off-by: Yingbao Jia <[email protected]>
commit 4615ac9 upstream. Commit 09c448d ("cpufreq: intel_pstate: Use IOWAIT flag in Atom algorithm") removed the last user of cpudata::prev_cummulative_iowait. Remove the member too. Found by https://github.com/jirislaby/clang-struct. Intel-SIG: commit 4615ac9 cpufreq: intel_pstate: remove cpudata. Backport intel_pstate driver update for 6.6 from 6.11 Signed-off-by: Jiri Slaby (SUSE) <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> [ Yingbao Jia: amend commit log ] Signed-off-by: Yingbao Jia <[email protected]>
…r_cleanup() commit f186b2d upstream. Remove the spinlock locking from intel_pstate_driver_cleanup() as it is not necessary because no other code accessing all_cpu_data[] can run in parallel with that function. Had the locking been necessary, though, it would have been incorrect because the lock in question is acquired from a hardirq handler and it cannot be acquired from thread context without disabling interrupts. Intel-SIG: commit f186b2d cpufreq: intel_pstate: Drop redundant locking from. Backport intel_pstate driver update for 6.6 from 6.11 Signed-off-by: Rafael J. Wysocki <[email protected]> [ Yingbao Jia: amend commit log ] Signed-off-by: Yingbao Jia <[email protected]>
commit 432acb2 upstream. Make intel_pstate_disable_hwp_interrupt() wait for canceled delayed work to complete to avoid leftover work items running when it returns which may be during driver unregistration and may confuse things going forward. Intel-SIG: commit 432acb2 cpufreq: intel_pstate: Wait for canceled delayed work to complete. Backport intel_pstate driver update for 6.6 from 6.11 Signed-off-by: Rafael J. Wysocki <[email protected]> [ Yingbao Jia: amend commit log ] Signed-off-by: Yingbao Jia <[email protected]>
commit 0f2828e upstream. Drop two redundant checks involving READ_ONCE() from notify_hwp_interrupt() and make it check hwp_active without READ_ONCE() which is not necessary, because that variable is only set once during the early initialization of the driver. In order to make that clear, annotate hwp_active with __ro_after_init. Intel-SIG: commit 0f2828e cpufreq: intel_pstate: Get rid of unnecessary READ_ONCE() annotations. Backport intel_pstate driver update for 6.6 from 6.11 Signed-off-by: Rafael J. Wysocki <[email protected]> [ Yingbao Jia: amend commit log ] Signed-off-by: Yingbao Jia <[email protected]>
commit e97a982 upstream. There are at least 3 variables in intel_pstate that do not get updated after they have been initialized, so annotate them with __ro_after_init. Intel-SIG: commit e97a982 cpufreq: intel_pstate: Use __ro_after_init for three variables. Backport intel_pstate driver update for 6.6 from 6.11 Signed-off-by: Rafael J. Wysocki <[email protected]> [ Yingbao Jia: amend commit log ] Signed-off-by: Yingbao Jia <[email protected]>
commit 032c556 upstream. Fold intel_pstate_max_within_limits() into its only caller. No functional impact. Intel-SIG: commit 032c556 cpufreq: intel_pstate: Fold intel_pstate_max_within_limits() into caller. Backport intel_pstate driver update for 6.6 from 6.11 Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Srinivas Pandruvada <[email protected]> [ Yingbao Jia: amend commit log ] Signed-off-by: Yingbao Jia <[email protected]>
…ialization commit 0940f1a upstream. The global.turbo_disabled is updated quite often, especially in the passive mode in which case it is updated every time the scheduler calls into the driver. However, this is generally not necessary and it adds MSR read overhead to scheduler code paths (and that particular MSR is slow to read). For this reason, make the driver read MSR_IA32_MISC_ENABLE_TURBO_DISABLE just once at the cpufreq driver registration time and remove all of the in-flight updates of global.turbo_disabled. Intel-SIG: commit 0940f1a cpufreq: intel_pstate: Do not update global.turbo_disabled. Backport intel_pstate driver update for 6.6 from 6.11 Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Srinivas Pandruvada <[email protected]> [ Yingbao Jia: amend commit log ] Signed-off-by: Yingbao Jia <[email protected]>
commit c626a43 upstream. Now that global.turbo_disabled can only change at the cpufreq driver registration time, initialize global.no_turbo at that time too so they are in sync to start with (if the former is set, the latter cannot be updated later anyway). That allows show_no_turbo() to be simlified because it does not need to check global.turbo_disabled and store_no_turbo() can be rearranged to avoid doing anything if the new value of global.no_turbo is equal to the current one and only return an error on attempts to clear global.no_turbo when global.turbo_disabled. While at it, eliminate the redundant ret variable from store_no_turbo(). No intentional functional impact. Intel-SIG: commit c626a43 cpufreq: intel_pstate: Rearrange show_no_turbo() and store_no_turbo(). Backport intel_pstate driver update for 6.6 from 6.11 Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Srinivas Pandruvada <[email protected]> [ Yingbao Jia: amend commit log ] Signed-off-by: Yingbao Jia <[email protected]>
commit 9558fae upstream. Because global.no_turbo is generally not read under intel_pstate_driver_lock make store_no_turbo() use WRITE_ONCE() for updating it (this is the only place at which it is updated except for the initialization) and make the majority of places reading it use READ_ONCE(). Also remove redundant global.turbo_disabled checks from places that depend on the 'true' value of global.no_turbo because it can only be 'true' if global.turbo_disabled is also 'true'. Intel-SIG: commit 9558fae cpufreq: intel_pstate: Read global.no_turbo under READ_ONCE(). Backport intel_pstate driver update for 6.6 from 6.11 Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Srinivas Pandruvada <[email protected]> [ Yingbao Jia: amend commit log ] Signed-off-by: Yingbao Jia <[email protected]>
commit f32587d upstream. Replace the global.turbo_disabled in __intel_pstate_update_max_freq() with a global.no_turbo one to make store_no_turbo() actually update the maximum CPU frequency on the trubo preference changes, which needs to be consistent with arch_set_max_freq_ratio() called from there. For more consistency, replace the global.turbo_disabled checks in __intel_pstate_cpu_init() and intel_cpufreq_adjust_perf() with global.no_turbo checks either. Intel-SIG: commit f32587d cpufreq: intel_pstate: Replace three global.turbo_disabled checks. Backport intel_pstate driver update for 6.6 from 6.11 Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Srinivas Pandruvada <[email protected]> [ Yingbao Jia: amend commit log ] Signed-off-by: Yingbao Jia <[email protected]>
commit e8217b4 upstream. There are 3 places at which the maximum CPU frequency may change, store_no_turbo(), intel_pstate_update_limits() (when called by the cpufreq core) and intel_pstate_notify_work() (when handling a HWP change notification). Currently, cpuinfo.max_freq is only updated by store_no_turbo() and intel_pstate_notify_work(), although it principle it may be necessary to update it in intel_pstate_update_limits() either. Make all of them mutually consistent. Intel-SIG: commit e8217b4 cpufreq: intel_pstate: Update the maximum CPU frequency consistently. Backport intel_pstate driver update for 6.6 from 6.11 Signed-off-by: Rafael J. Wysocki <[email protected]> Acked-by: Srinivas Pandruvada <[email protected]> [ Yingbao Jia: amend commit log ] Signed-off-by: Yingbao Jia <[email protected]>
commit 8c55654 upstream. The reference to this variable is hidden in an #ifdef: drivers/cpufreq/intel_pstate.c:2440:32: error: 'intel_pstate_cpu_oob_ids' defined but not used [-Werror=unused-const-variable=] Use the same check around the definition. Intel-SIG: commit 8c55654 cpufreq: intel_pstate: hide unused intel_pstate_cpu_oob_ids[]. Backport intel_pstate driver update for 6.6 from 6.11 Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> [ Yingbao Jia: amend commit log ] Signed-off-by: Yingbao Jia <[email protected]>
commit 0a206fe upstream. make C=1 currently gives the following warning: drivers/cpufreq/intel_pstate.c:262: warning: Function parameter or struct member 'epp_cached' not described in 'cpudata' Add the missing ":" to fix the trivial kernel-doc syntax error. Intel-SIG: commit 0a206fe cpufreq: intel_pstate: fix struct cpudata::epp_cached kernel-doc. Backport intel_pstate driver update for 6.6 from 6.11 Signed-off-by: Jeff Johnson <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> [ Yingbao Jia: amend commit log ] Signed-off-by: Yingbao Jia <[email protected]>
commit 1e24c31351787e24b7eebe84866bd55fd62a0aef upstream. Fix unchecked MSR access error for processors with no HWP support. On such processors, maximum frequency can be changed by the system firmware using ACPI event ACPI_PROCESSOR_NOTIFY_HIGEST_PERF_CHANGED. This results in accessing HWP MSR 0x771. Call Trace: <TASK> generic_exec_single+0x58/0x120 smp_call_function_single+0xbf/0x110 rdmsrl_on_cpu+0x46/0x60 intel_pstate_get_hwp_cap+0x1b/0x70 intel_pstate_update_limits+0x2a/0x60 acpi_processor_notify+0xb7/0x140 acpi_ev_notify_dispatch+0x3b/0x60 HWP MSR 0x771 can be only read on a CPU which supports HWP and enabled. Hence intel_pstate_get_hwp_cap() can only be called when hwp_active is true. Intel-SIG: commit 1e24c3135178 cpufreq: intel_pstate: Fix unchecked HWP MSR access. Backport intel_pstate driver update for 6.6 from 6.11 Reported-by: Sebastian Andrzej Siewior <[email protected]> Closes: https://lore.kernel.org/linux-pm/[email protected]/ Fixes: e8217b4 ("cpufreq: intel_pstate: Update the maximum CPU frequency consistently") Tested-by: Sebastian Andrzej Siewior <[email protected]> Signed-off-by: Srinivas Pandruvada <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> [ Yingbao Jia: amend commit log ] Signed-off-by: Yingbao Jia <[email protected]>
commit 350cbb5d2f676bff22c49e5e81764c3b8da342a9 upstream. After recent changes in intel_pstate, global.turbo_disabled is only set at the initialization time and never changed. However, it turns out that on some systems the "turbo disabled" bit in MSR_IA32_MISC_ENABLE, the initial state of which is reflected by global.turbo_disabled, can be flipped later and there should be a way to take that into account (other than checking that MSR every time the driver runs which is costly and useless overhead on the vast majority of systems). For this purpose, notice that before the changes in question, store_no_turbo() contained a turbo_is_disabled() check that was used for updating global.turbo_disabled if the "turbo disabled" bit in MSR_IA32_MISC_ENABLE had been flipped and that functionality can be restored. Then, users will be able to reset global.turbo_disabled by writing 0 to no_turbo which used to work before on systems with flipping "turbo disabled" bit. This guarantees the driver state to remain in sync, but READ_ONCE() annotations need to be added in two places where global.turbo_disabled is accessed locklessly, so modify the driver to make that happen. Intel-SIG: commit 350cbb5d2f67 cpufreq: intel_pstate: Check turbo_is_disabled() in store_no_turbo(). Backport intel_pstate driver update for 6.6 from 6.11 Fixes: 0940f1a ("cpufreq: intel_pstate: Do not update global.turbo_disabled after initialization") Closes: https://lore.kernel.org/linux-pm/[email protected] Suggested-by: Srinivas Pandruvada <[email protected]> Reported-by: Xi Ruoyao <[email protected]> Tested-by: Xi Ruoyao <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> [ Yingbao Jia: amend commit log ] Signed-off-by: Yingbao Jia <[email protected]>
commit 7ea81936b85317aee8a73cd35d7f9cd6ce654dee upstream. When CPUID[6].EAX[15] is set to 1, this CPU supports notification for HWP (Hardware P-states) highest performance change. Add a feature flag to check if the CPU supports HWP highest performance change. Intel-SIG: commit 7ea81936b853 x86/cpufeatures: Add HWP highest perf change feature flag. Backport intel_pstate driver update for 6.6 from 6.11 Signed-off-by: Srinivas Pandruvada <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Rafael J. Wysocki <[email protected]> [ Yingbao Jia: amend commit log ] Signed-off-by: Yingbao Jia <[email protected]>
commit acfc429e42f09524653af52998548cd9317892a6 upstream. Replace boot_cpu_has() with cpu_feature_enabled(). Intel-SIG: commit acfc429e42f0 cpufreq: intel_pstate: Replace boot_cpu_has(). Backport intel_pstate driver update for 6.6 from 6.11 Signed-off-by: Srinivas Pandruvada <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Rafael J. Wysocki <[email protected]> [ Yingbao Jia: amend commit log ] Signed-off-by: Yingbao Jia <[email protected]>
commit d845cd901b28f1b6c02a208b864fc3fc46d14536 upstream. On some systems, the HWP (Hardware P-states) highest performance level can change from the value set at boot-up. This behavior can lead to two issues: - The 'cpuinfo_max_freq' within the 'cpufreq' sysfs will not reflect the CPU's highest achievable performance. - Even if the CPU's highest performance level is increased after booting, the CPU may not reach the full expected performance. The availability of this feature is indicated by the CPUID instruction: if CPUID[6].EAX[15] is set to 1, the feature is supported. When supported, setting bit 2 of the MSR_HWP_INTERRUPT register enables notifications of the highest performance level changes. Therefore, as part of enabling the HWP interrupt, bit 2 of the MSR_HWP_INTERRUPT should also be set when this feature is supported. Upon a change in the highest performance level, a new HWP interrupt is generated, with bit 3 of the MSR_HWP_STATUS register set, and the MSR_HWP_CAPABILITIES register is updated with the new highest performance limit. The processing of the interrupt is the same as the guaranteed performance change. Notify change to cpufreq core and update MSR_HWP_REQUEST with new performance limits. The current driver implementation already takes care of the highest performance change as part of: commit dfeeedc ("cpufreq: intel_pstate: Update cpuinfo.max_freq on HWP_CAP changes") For example: Before highest performance change interrupt: cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 3700000 cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq 3700000 After highest performance changes interrupt: cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq 3900000 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 3900000 Intel-SIG: commit d845cd901b28 cpufreq: intel_pstate: Support highest performance change interrupt. Backport intel_pstate driver update for 6.6 from 6.11 Signed-off-by: Srinivas Pandruvada <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Rafael J. Wysocki <[email protected]> [ Yingbao Jia: amend commit log ] Signed-off-by: Yingbao Jia <[email protected]>
commit 64a66f4a3c89b4602ee1e6cd23b28729fc4562b3 upstream. On Intel Emerald Rapids machines, we ship the Energy Performance Preference (EPP) default for balance_performance as 128. However, during an internal investigation together with Intel, we have determined that 32 is a more suitable value. This leads to significant improvements in both performance and energy: POV-Ray: 32% faster | 12% less energy OpenSSL: 12% faster | energy within 1% Build Linux Kernel: 29% faster | 18% less energy Therefore, we should move the default EPP for balance_performance to 32. This is in line with what has already been done for Sapphire Rapids. Intel-SIG: commit 64a66f4a3c89 cpufreq: intel_pstate: Update Balance performance EPP for Emerald Rapids. Backport intel_pstate driver update for 6.6 from 6.11 Signed-off-by: Pedro Henrique Kopper <[email protected]> Acked-by: Srinivas Pandruvada <[email protected]> Link: https://patch.msgid.link/Zqu6zjVMoiXwROBI@capivara Signed-off-by: Rafael J. Wysocki <[email protected]> [ Yingbao Jia: amend commit log ] Signed-off-by: Yingbao Jia <[email protected]>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
deepin pr auto review代码审查意见：
|
|
测试通过 |
Avenger-285714
merged commit 6670141
into
deepin-community:linux-6.6.y
backport update and fix:
Support highest performance change interrupt
Allow model specific EPPs and set balanced EPP for EMR and SPR
other update
Test:
intel_pstate driver works as expected and also cpupower and turbostat to check frequency info
Link: https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel/pulls/277