Conversation
|
• Thanks for the detailed MR description and the current unit test output. I see that the test section covers amd_pstate=active bring-up, CPPC-derived In particular, this series lists CPPC_REQ2/FLOOR_PERF and the So the current test log does not demonstrate that CPPC Performance Priority is Could you please add Venice-specific validation details for this feature? I am
In summary, could you please provide a deterministic Venice validation |
2e4337d to
2d90382
Compare
Thanks for the detailed review. Please find the details below: 1. Confirm feature support: Result: 2. Decode REQ2 and choose floor values: MSR_AMD_CPPC_REQ2 (0xc00102b5) low byte [7:0] = FLOOR_PERF. At boot: 0x...91 = 145 = nominal_perf. 3 & 4. Workload, expected behavior, pass/fail: 5. Observability — before/after: Use direct REQ2 read + amd_pstate_cppc_req2 tracepoint for the write, and turbostat for the effect: The REQ2 low byte moves from 0x91→0xff, the tracepoint confirms the write (changed=1, error=0), and turbostat shows the busy frequency held at the floor on an otherwise-idle core. PASS — floor write latches and is observable. Please let me know if you need any further information. Thanks. |
|
I did one more retest for the CPPC priority / amd_pstate_floor_freq behavior Test environment:
Test setup:
Observed result:
Example results:
So the priority effect is visible because the high-floor group keeps a much Could you help confirm whether this is the expected hardware/SMU behavior? |
Hi, Thanks for sharing the test details. Please find the explanation for the results. In summary: Details: Setup: HIGH floor ~3500 MHz (FLOOR_PERF 254) on 18 complete physical cores (both SMT siblings in the same group), LOW floor ~1800 MHz (FLOOR_PERF 131) on the rest. Workload: stress-ng --matrix 0 --matrix-method prod on all CPUs. An all-core matrixprod load drives the package to its stock PPT (~521 W), which supplies the constraint. Same as your finding: the high-floor group is clearly protected (~940 MHz higher), but it does not hold the requested 3500 MHz floor, and the low group is not pinned at exactly 1800 MHz. To your questions: Yes — topology and local power/thermal limits can reduce a high-floor core while a low-floor core stays above its floor. The package budget is arbitrated globally by the SMU, but per-core V/F curves and per-CCD current (EDC/TDC)/thermal limits are local, so strict cross-core ordering ("all low cores at LOW floor before any high core drops below HIGH floor") is not something the feature provides or intends. Why HIGH lands below 3500 and LOW above 1800: at the cap, the high group's aggregate demand exceeds the budget, so the SMU protects it relatively but scales it down to stay within power; the low floor is a minimum target, not a setpoint, so low cores float wherever budget allows. Tightening the cap pushes the low group toward 1800 first. Thanks. |
|
Hello, here is a another issue I met: Test environment:
I changed only the HIGH floor while keeping the same workload running: A0 result:
So the relative HIGH/LOW split tracks the configured HIGH floor:
The part I would like to clarify is the expected behavior when there still When all CPUs use the same floor value, the same workload can run around Is this expected firmware/SMU behavior for CPPC Performance Priority? In other words, should different FLOOR_PERF values be interpreted not only as a |
Hi, CPPC Performance Priority — redistribution below the external power limit: Yes — this is expected firmware/SMU behavior, and your interpretation is correct: Why redistribution happens below the 500 W cap: The HSMP socket power limit is only one of several limiters the SMU enforces
With LOW=1800 and HIGH=3500, FLOOR_PERF tells the SMU to commit the shared Why split-config power (438 W) is lower than uniform 3.5 GHz (500 W): Dropping the LOW group to ~2.6 GHz lowers its voltage and power substantially In summary: FLOOR_PERF should be read as both: a throttling preference under a saturated Thanks. |
Thanks for your reply, that explanation is helpful. One concern I still have is about the In this test, the workload is unchanged. With a uniform floor, the whole socket can So the HIGH group does not appear to gain additional frequency compared with the Is this intended behavior? In other words, is CPPC Performance Priority expected I understand that FloorPerf is a priority hint and not a fixed frequency request.
|
|
Hello CI reports missing upstream fix patches for this branch. The fix-patch scan checked 227 commits and found several missing fixes. Some of Missing fixes reported by CI:
There are also several non-amd-pstate fixes reported by the same scan:
|
Hi Kchuyizhou, Thank you for the detailed test data and the very clear write-up — the four-point HIGH-floor sweep with turbostat sampling made the behavior easy to reproduce and reason about on our side. Short answer: Yes, what you are observing is expected firmware/SMU behavior, not a defect or a misreport of available power. Different per-core MinPerf (FLOOR_PERF) values are interpreted as more than a throttling-order preference under a saturated power/thermal cap — they act as guaranteed minimum active-frequency targets that the SMU's DPM arbitration satisfies first, which effectively makes them an internal performance-priority signal. That priority can redistribute performance between your HIGH and LOW groups even before the package reaches the 500 W socket limit. Why the numbers look the way they do: This also explains the clean monotonic trend you captured: HIGH floor PkgWatt HIGH MHz LOW MHz Δ As you noted: reducing the HIGH floor reduces the split; setting HIGH = LOW removes it; setting HIGH = scaling_max_freq maximizes it. That is consistent with MinPerf being honored as a priority/guaranteed-minimum input to the arbitration rather than a pure power-cap throttle. The platform is intended to support core-priority — allowing the SMU to prioritize frequency allocation (and throttling) by core rather than treating all cores uniformly. Using divergent MinPerf floors is effectively a way to express that priority. • If the goal is to fully utilize package power while still favoring the HIGH cores, raising the LOW-group floor (rather than lowering it) will pull more of the available budget back into the LOW group and push package power back toward 500 W, while the HIGH floor continues to guarantee the priority cores. Sample run output: ================ RESULTS (Bzy_MHz; D = HIGH-LOW separation) ================ --- LOW=2500MHz(0xb5): HW read-back -> HIGH=3503MHz LOW=2497MHz --- --- LOW=3000MHz(0xd9): HW read-back -> HIGH=3503MHz LOW=2993MHz --- • If the goal is strict prioritization of the 18 HIGH cores, the current configuration is working as intended — the unused power is expected, not lost throughput that should have been reclaimed. Please let us know if you need any further information. Thanks. |
Hi Kchuyizhou, Some of these patches identified in the scan were not originally scoped for this backport, as they had not been upstreamed at that time. They have now been recently upstreamed as part of version 7.1. We will analyze and backport the remaining fix patches and submit them for review. Kindly advise whether these patches should be included in the current PR or submitted as a new PR. Thanks. |
Hi, Thanks for the update. Since the CI scan is based on the commits included in this MR, the reported For the fixes that are related to amd-pstate / ACPI CPPC / dynamic EPP / For any reported fix whose original patch is not really related to the CPPC |
Hi, All fix patches identified by the fix‑patch scan have been backported, tested, and included in this PR, except the following: 4490fe973669 – platform/x86/amd: pmf: Fix missing hidden options for Smart PC Test Results (Fix Patches) Results before and after backport (also included in the PR summary under unit test results):
Please help with the review. Thanks. |
Could you completely drop the following two patches from the current MR? Because as long as these two patches remain in the current branch, our CI will definitely require |
Hi, Commit: 688834743d672b - ACPI: platform_profile: Allow multiple handlers Thanks. |
I see.... So could we further drop the following patch or its related patches? Is this feasible? |
The following patch is a base ACPI patch that introduces support for multiple handlers and cannot be removed. Removing it will lead to platform profiler functionality failures. |
|
Hi, Simply consider dropping |
Hi, Kindly review & let us know your feedback. Thanks. |
d0952ee to
25345f1
Compare
…ally commit e571a5e upstream. Preferred core rankings can be changed dynamically by the platform based on the workload and platform conditions and accounting for thermals and aging. When this occurs, cpu priority need to be set. Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Wyes Karny <wyes.karny@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Perry Yuan <perry.yuan@amd.com> Signed-off-by: Meng Li <li.meng@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Abhishek Rajput <Abhishek.Rajput@amd.com> Signed-off-by: mohanasv2 <mohanasv@amd.com>
commit b37ef72 upstream. The four fields of struct cpudata namely min_limit_perf, max_limit_perf, min_limit_freq, max_limit_freq introduced in the commit febab20("cpufreq/amd-pstate: Fix scaling_min_freq and scaling_max_freq update") are currently undocumented Add comments describing these fields Acked-by: Huang Rui <ray.huang@amd.com> Fixes: febab20("cpufreq/amd-pstate: Fix scaling_min_freq and scaling_max_freq update") Reviewed-by: Li Meng <li.meng@amd.com> Tested-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Perry Yuan <perry.yuan@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Abhishek Rajput <Abhishek.Rajput@amd.com> Signed-off-by: mohanasv2 <mohanasv@amd.com>
…data commit 4fcfd19 upstream. The min_limit_freq, max_limit_freq, min_freq, max_freq, nominal_freq and the lowest_nominal_freq members of struct cpudata store the frequency value in khz to be consistent with the cpufreq core. Update the comment to document this. Reviewed-by: Li Meng <li.meng@amd.com> Tested-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Perry Yuan <perry.yuan@amd.com> Acked-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Abhishek Rajput <Abhishek.Rajput@amd.com> Signed-off-by: mohanasv2 <mohanasv@amd.com>
…linear}_freq commit 5547c0e upstream. Currently the amd_get_{min, max, nominal, lowest_nonlinear}_freq() helpers computes the values of min_freq, max_freq, nominal_freq and lowest_nominal_freq respectively afresh from cppc_get_perf_caps(). This is not necessary as there are fields in cpudata to cache these values. To simplify this, add a single helper function named amd_pstate_init_freq() which computes all these frequencies at once, and caches it in cpudata. Use the cached values everywhere else in the code. Acked-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Li Meng <li.meng@amd.com> Tested-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Co-developed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Perry Yuan <perry.yuan@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Abhishek Rajput <Abhishek.Rajput@amd.com> Signed-off-by: mohanasv2 <mohanasv@amd.com>
…}_freq() commit 3cbbe88 upstream. amd_get_{min,max,nominal,lowest_nonlinear}_freq() functions merely return cpudata->{min,max,nominal,lowest_nonlinear}_freq values. There is no loss in readability in replacing their invocations by accesses to the corresponding members of cpudata. Do so and remove these helper functions. Acked-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Li Meng <li.meng@amd.com> Tested-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Perry Yuan <perry.yuan@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Abhishek Rajput <Abhishek.Rajput@amd.com> Signed-off-by: mohanasv2 <mohanasv@amd.com>
commit 2ddb8a3 upstream. The amd-pstate driver cannot work when the min_freq, nominal_freq or the max_freq is zero. When this happens it is prudent to error out early on rather than waiting failing at the time of the governor initialization. Acked-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Tested-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Signed-off-by: Perry Yuan <perry.yuan@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Abhishek Rajput <Abhishek.Rajput@amd.com> Signed-off-by: mohanasv2 <mohanasv@amd.com>
… tables commit 069a2bb upstream. Make pstate driver initially retrieve the P-state transition delay and latency values from the BIOS ACPI tables which has more reasonable delay and latency values according to the platform design and requirements. Previously there values were hardcoded at specific value which may have conflicted with platform and it might not reflect the most accurate or optimized setting for the processor. [054h 0084 8] Preserve Mask : FFFFFFFF00000000 [05Ch 0092 8] Write Mask : 0000000000000001 [064h 0100 4] Command Latency : 00000FA0 [068h 0104 4] Maximum Access Rate : 0000EA60 [06Ch 0108 2] Minimum Turnaround Time : 0000 Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Tested-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Signed-off-by: Perry Yuan <perry.yuan@amd.com> Acked-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Abhishek Rajput <Abhishek.Rajput@amd.com> Signed-off-by: mohanasv2 <mohanasv@amd.com>
commit eb8b6c3 upstream. Add quirks table to get CPPC capabilities issue fixed by providing correct perf or frequency values while driver loading. If CPPC capabilities are not defined in the ACPI tables or wrongly defined by platform firmware, it needs to use quick to get those issues fixed with correct workaround values to make pstate driver can be loaded even though there are CPPC capabilities errors. The workaround will match the broken BIOS which lack of CPPC capabilities nominal_freq and lowest_freq definition in the ACPI table. $ cat /sys/devices/system/cpu/cpu0/acpi_cppc/lowest_freq 0 $ cat /sys/devices/system/cpu/cpu0/acpi_cppc/nominal_freq 0 Acked-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Tested-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com> Signed-off-by: Perry Yuan <perry.yuan@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Abhishek Rajput <Abhishek.Rajput@amd.com> Signed-off-by: mohanasv2 <mohanasv@amd.com>
commit 5131a3c upstream. get some code format problems fixed in the amd-pstate driver. Changes Made: - Fixed incorrect comment format in the functions. - Removed unnecessary blank line. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202404271148.HK9yHBlB-lkp@intel.com/ Signed-off-by: Perry Yuan <perry.yuan@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Abhishek Rajput <Abhishek.Rajput@amd.com> Signed-off-by: mohanasv2 <mohanasv@amd.com>
… line options commit dfddf34 upstream. amd-pstate driver support enable/disable preferred core. Default enabled on platforms supporting amd-pstate preferred core. Disable amd-pstate preferred core with "amd_prefcore=disable" added to the kernel command line. Signed-off-by: Meng Li <li.meng@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Wyes Karny <wyes.karny@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Perry Yuan <perry.yuan@amd.com> Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: chaithanyaLagisetty <LagisettyVenkata.NagaChaitanya@amd.com> Signed-off-by: mohanasv2 <mohanasv@amd.com>
commit da8afb1c666a4a966f0ab91dc336df4c855bc7b2 upstream. Add `amd_dynamic_epp=enable` and `amd_dynamic_epp=disable` to override the kernel configuration option `CONFIG_X86_AMD_PSTATE_DYNAMIC_EPP` locally. Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: chaithanyaLagisetty <LagisettyVenkata.NagaChaitanya@amd.com> Signed-off-by: mohanasv2 <mohanasv@amd.com>
commit c03791085adcd61fa9b766ab303c7d0941d7378d upstream. cpufreq_cpu_get() can sleep on PREEMPT_RT in presence of concurrent writer(s), however amd-pstate depends on fetching the cpudata via the policy's driver data which necessitates grabbing the reference. Since schedutil governor can call "cpufreq_driver->update_perf()" during sched_tick/enqueue/dequeue with rq_lock held and IRQs disabled, fetching the policy object using the cpufreq_cpu_get() helper in the scheduler fast-path leads to "BUG: scheduling while atomic" on PREEMPT_RT [1]. Pass the cached cpufreq policy object in sg_policy to the update_perf() instead of just the CPU. The CPU can be inferred using "policy->cpu". The lifetime of cpufreq_policy object outlasts that of the governor and the cpufreq driver (allocated when the CPU is onlined and only reclaimed when the CPU is offlined / the CPU device is removed) which makes it safe to be referenced throughout the governor's lifetime. Closes:https://lore.kernel.org/all/20250731092316.3191-1-spasswolf@web.de/ [1] [Backport Changes] Upstream changes to rust/kernel/cpufreq.rs were excluded. The Rust cpufreq abstraction does not yet exist in the Anolis 6.6 kernel tree; only the C cpufreq core (drivers/cpufreq/cpufreq.c, intel_pstate.c, amd-pstate.c), the cpufreq schedutil governor, and include/linux/cpufreq.h hunks are applied. Fixes: 1d215f0 ("cpufreq: amd-pstate: Add fast switch function for AMD P-State") Reported-by: Bert Karwatzki <spasswolf@web.de> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com> Acked-by: Gary Guo <gary@garyguo.net> # Rust Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260316081849.19368-3-kprateek.nayak@amd.com Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Hemanth Selam <Hemanth.Selam@amd.com> Signed-off-by: mohanasv2 <mohanasv@amd.com>
commit 86d71f1d7686cecebbafb371ad58c6ad7f80a93a upstream. All callers of amd_pstate_update() already have a reference to the cpufreq_policy object. Pass the entire policy object and grab the cpudata using "policy->driver_data" instead of passing the cpudata and unnecessarily grabbing another read-side reference to the cpufreq policy object when it is already available in the caller. No functional changes intended. Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com> Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Link: https://lore.kernel.org/r/20260316081849.19368-2-kprateek.nayak@amd.com Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Hemanth Selam <Hemanth.Selam@amd.com> Signed-off-by: mohanasv2 <mohanasv@amd.com>
commit 077f23573d29d063a950e90aa77c8e1f79580147 upstream. In case a new index is introduced add a static assert to make sure that strings and values are updated. Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Hemanth Selam <Hemanth.Selam@amd.com> Signed-off-by: mohanasv2 <mohanasv@amd.com>
commit 6927f21852f38db2975b5d5539cbe5241c25a99b upstream. The energy performance preference field of the CPPC request MSR supports values from 0 to 255, but the strings only offer 4 values. The other values are useful for tuning the performance of some workloads. Add support for writing the raw energy performance preference value to the sysfs file. If the last value written was an integer then an integer will be returned. If the last value written was a string then a string will be returned. Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Hemanth Selam <Hemanth.Selam@amd.com> Signed-off-by: mohanasv2 <mohanasv@amd.com>
commit 7e173bc310d2b1df018edc66334a5304305889a2 upstream. Ensure that all supported raw EPP values work properly. Export the driver helpers used by the test module so the test can drive raw EPP writes and temporarily disable dynamic EPP while it runs. Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Hemanth Selam <Hemanth.Selam@amd.com> Signed-off-by: mohanasv2 <mohanasv@amd.com>
…ewer commit 9487e2a00e7b3c6f258c5c99953f470eba6fb61d upstream. Mario Limonciello has led amd-pstate maintenance in recent years and has done excellent work. The amd-pstate driver is in good hands with him. I am stepping down as co-maintainer as I move on to other things. Add K Prateek Nayak as a reviewer. He has been actively contributing to the driver including preferred-core and ITMT improvements, and has been helping review amd-pstate patches for a while now. [Backport Changes] The MAINTAINERS entry for the AMD PSTATE DRIVER in this tree does not contain the line "M: Gautham R. Shenoy <gautham.shenoy@amd.com>", so the hunk that removes it was dropped. Only the upstream change that adds the new reviewer was applied. Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Acked-by: K Prateek Nayak <kprateek.nayak@amd.com> Acked-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://lore.kernel.org/r/20260402102611.16519-1-gautham.shenoy@amd.com Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Hemanth Selam <Hemanth.Selam@amd.com> Signed-off-by: mohanasv2 <mohanasv@amd.com>
…ration commit a97e293 upstream. Modify intel_pstate_register_driver() to clear hybrid_max_perf_cpu before calling cpufreq_register_driver(), so that asymmetric CPU capacity scaling is not updated until hybrid_init_cpu_capacity_scaling() runs down the road. This is done in preparation for a subsequent change adding asymmetric CPU capacity computation to the CPU init path to handle CPUs that are initially offline. The information on whether or not hybrid_max_perf_cpu was NULL before it has been cleared is passed to hybrid_init_cpu_capacity_scaling(), so full initialization of CPU capacity scaling can be skipped if it has been carried out already. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/4616631.LvFx2qVVIh@rjwysocki.net Signed-off-by: Hemanth Selam <Hemanth.Selam@amd.com> Signed-off-by: mohanasv2 <mohanasv@amd.com>
commit b79276d upstream. arch_init_invariance_cppc() is called at the end of acpi_cppc_processor_probe() in order to configure frequency invariance based upon the values from _CPC. This however doesn't work on AMD CPPC shared memory designs that have AMD preferred cores enabled because _CPC needs to be analyzed from all cores to judge if preferred cores are enabled. This issue manifests to users as a warning since commit 21fb59a ("ACPI: CPPC: Adjust debug messages in amd_set_max_freq_ratio() to warn"): ``` Could not retrieve highest performance (-19) ``` However the warning isn't the cause of this, it was actually commit 279f838 ("x86/amd: Detect preferred cores in amd_get_boost_ratio_numerator()") which exposed the issue. To fix this problem, change arch_init_invariance_cppc() into a new weak symbol that is called at the end of acpi_processor_driver_init(). Each architecture that supports it can declare the symbol to override the weak one. Define it for x86, in arch/x86/kernel/acpi/cppc.c, and for all of the architectures using the generic arch_topology.c code. Fixes: 279f838 ("x86/amd: Detect preferred cores in amd_get_boost_ratio_numerator()") Reported-by: Ivan Shapovalov <intelfx@intelfx.name> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219431 Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://patch.msgid.link/20241104222855.3959267-1-superm1@kernel.org [ rjw: Changelog edit ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hemanth Selam <Hemanth.Selam@amd.com> Signed-off-by: mohanasv2 <mohanasv@amd.com>
…e initially commit 92447aa upstream. Commit 929ebc9 ("cpufreq: intel_pstate: Set asymmetric CPU capacity on hybrid systems") overlooked a corner case in which some CPUs may be offline to start with and brought back online later, after the intel_pstate driver has been registered, so their asymmetric capacity will not be set. Address this by calling hybrid_update_capacity() in the CPU initialization path that is executed instead of the online path for those CPUs. Note that this asymmetric capacity update will be skipped during driver initialization and mode switches because hybrid_max_perf_cpu is NULL in those cases. Fixes: 929ebc9 ("cpufreq: intel_pstate: Set asymmetric CPU capacity on hybrid systems") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/1913414.tdWV9SEqCh@rjwysocki.net Signed-off-by: Hemanth Selam <Hemanth.Selam@amd.com> Signed-off-by: mohanasv2 <mohanasv@amd.com>
…scaling() commit 1a1030d upstream. Notice that hybrid_init_cpu_capacity_scaling() only needs to hold hybrid_capacity_lock around __hybrid_init_cpu_capacity_scaling() calls, so introduce a "locked" wrapper around the latter and call it from the former. This allows to drop a local variable and a label that are not needed any more. Also, rename __hybrid_init_cpu_capacity_scaling() to __hybrid_refresh_cpu_capacity_scaling() for consistency. Interestingly enough, this fixes a locking issue introduced by commit 929ebc9 ("cpufreq: intel_pstate: Set asymmetric CPU capacity on hybrid systems") that put an arch_enable_hybrid_capacity_scale() call under hybrid_capacity_lock, which was a mistake because the latter is acquired in CPU hotplug paths and so it cannot be held around cpus_read_lock() calls. Link: https://lore.kernel.org/linux-pm/SJ1PR11MB6129EDBF22F8A90FC3A3EDC8B9582@SJ1PR11MB6129.namprd11.prod.outlook.com/ Fixes: 929ebc9 ("cpufreq: intel_pstate: Set asymmetric CPU capacity on hybrid systems") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reported-by: "Borah, Chaitanya Kumar" <chaitanya.kumar.borah@intel.com> Link: https://patch.msgid.link/12554508.O9o76ZdvQC@rjwysocki.net [ rjw: Changelog update ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hemanth Selam <Hemanth.Selam@amd.com> Signed-off-by: mohanasv2 <mohanasv@amd.com>
…erformance governor
commit 220abf77e7c2835cc63ea8cd7158cf83952640af upstream.
In the "active" mode of the amd-pstate driver with performance
governor, the CPPC.min_perf is expected to be the nominal_perf.
However after commit a9b9b4c2a4cd ("cpufreq/amd-pstate: Drop min and
max cached frequencies"), this is not the case when the governor is
switched from performance to powersave and back to performance, and
the CPPC.min_perf will be equal to the scaling_min_freq that was set
for the powersave governor.
This is because prior to commit a9b9b4c2a4cd ("cpufreq/amd-pstate:
Drop min and max cached frequencies"), amd_pstate_epp_update_limit()
would unconditionally call amd_pstate_update_min_max_limit() and the
latter function would enforce the CPPC.min_perf constraint when the
governor is performance.
However, after the aforementioned commit,
amd_pstate_update_min_max_limit() is called by
amd_pstate_epp_update_limit() only when either the
scaling_{min/max}_freq is different from the cached value of
cpudata->{min/max}_limit_freq, which wouldn't have changed on a
governor transition from powersave to performance, thus missing out on
enforcing the CPPC.min_perf constraint for the performance governor.
Fix this by invoking amd_pstate_epp_udpate_limit() not only when the
{min/max} limits have changed from the cached values, but also when
the policy itself has changed.
Fixes: a9b9b4c2a4cd ("cpufreq/amd-pstate: Drop min and max cached frequencies")
Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20250821042638.356-1-gautham.shenoy@amd.com
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Hemanth Selam <Hemanth.Selam@amd.com>
Signed-off-by: mohanasv2 <mohanasv@amd.com>
commit 4fe5934db4a7187d358f1af1b3ef9b6dd59bce58 upstream. Commit 279f838 ("x86/amd: Detect preferred cores in amd_get_boost_ratio_numerator()") introduced the ability to detect the preferred core on AMD platforms by checking if there at least two distinct highest_perf values. However, it uses for_each_present_cpu() to iterate through all the CPUs in the platform, which is problematic when the kernel is booted with "nosmt=force" commandline option. Hence limit the search to only the online CPUs. Fixes: 279f838 ("x86/amd: Detect preferred cores in amd_get_boost_ratio_numerator()") Reported-by: Christopher Harris <chris.harris79@gmail.com> Closes: https://lore.kernel.org/lkml/CAM+eXpdDT7KjLV0AxEwOLkSJ2QtrsvGvjA2cCHvt1d0k2_C4Cw@mail.gmail.com/ Reviewed-by: "Mario Limonciello (AMD) (kernel.org)" <superm1@kernel.org> Tested-by: Chrisopher Harris <chris.harris79@gmail.com> Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Link: https://patch.msgid.link/20251107074145.2340-2-gautham.shenoy@amd.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hemanth Selam <Hemanth.Selam@amd.com> Signed-off-by: mohanasv2 <mohanasv@amd.com>
…possible commit 1fedbb589448bee9f20bb2ed9c850d1d2cf9963c upstream. According to the description in the intel_pstate.rst documentation, Capacity-Aware Scheduling and Energy-Aware Scheduling are only supported on a hybrid processor without SMT. Previously, the system used sched_smt_active() for judgment, which is not a strict condition because users can switch it on or off via /sys at any time. This could lead to incorrect driver settings in certain scenarios. For example, on a CPU that supports SMT, a user can disable SMT via the nosmt parameter to enable asym capacity, and then re-enable SMT via /sys. In such cases, some settings in the driver would no longer be correct. To address this issue, replace sched_smt_active() with cpu_smt_possible(), and only enable asym capacity when CPU SMT is not possible. Fixes: 929ebc9 ("cpufreq: intel_pstate: Set asymmetric CPU capacity on hybrid systems") Signed-off-by: Yaxiong Tian <tianyaxiong@kylinos.cn> [ rjw: Subject and changelog edits ] Link: https://patch.msgid.link/20260203024852.301066-1-tianyaxiong@kylinos.cn Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hemanth Selam <Hemanth.Selam@amd.com> Signed-off-by: mohanasv2 <mohanasv@amd.com>
commit 5f2ec3536d7933a804d28d2541e4e918ba32587b upstream. Follow cleanup.h recommendations and define and assign a variable in one statement when __free() is used. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Zihuan Zhang <zhangzihuan@kylinos.cn> Link: https://patch.msgid.link/2251447.irdbgypaU6@rafael.j.wysocki Signed-off-by: Hemanth Selam <Hemanth.Selam@amd.com> Signed-off-by: mohanasv2 <mohanasv@amd.com>
commit 6b050482ec40569429d963ac52afa878691b04c9 upstream. When the system is booted with kernel command line argument "nosmt" or "maxcpus" to limit the number of CPUs, disabling turbo via: echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo results in a crash: PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI ... RIP: 0010:store_no_turbo+0x100/0x1f0 ... This occurs because for_each_possible_cpu() returns CPUs even if they are not online. For those CPUs, all_cpu_data[] will be NULL. Since commit 973207ae3d7c ("cpufreq: intel_pstate: Rearrange max frequency updates handling code"), all_cpu_data[] is dereferenced even for CPUs which are not online, causing the NULL pointer dereference. To fix that, pass CPU number to intel_pstate_update_max_freq() and use all_cpu_data[] for those CPUs for which there is a valid cpufreq policy. Fixes: 973207ae3d7c ("cpufreq: intel_pstate: Rearrange max frequency updates handling code") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221068 Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: 6.16+ <stable@vger.kernel.org> # 6.16+ Link: https://patch.msgid.link/20260225001752.890164-1-srinivas.pandruvada@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hemanth Selam <Hemanth.Selam@amd.com> Signed-off-by: mohanasv2 <mohanasv@amd.com>
commit 679343977588781bd3effba79e9644aee4ee046c upstream.
The dynamic EPP feature uses power_supply_reg_notifier() and
power_supply_unreg_notifier() but doesn't declare a dependency on
POWER_SUPPLY, causing linker errors when POWER_SUPPLY is not enabled.
Add POWER_SUPPLY to the selects.
Suggested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Fixes: e30ca6dd5345 ("cpufreq/amd-pstate: Add dynamic energy performance preference")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202604040742.ySEdkuAa-lkp@intel.com/
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://patch.msgid.link/20260407194949.310114-1-mario.limonciello@amd.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Hemanth Selam <Hemanth.Selam@amd.com>
Signed-off-by: mohanasv2 <mohanasv@amd.com>
…ic_epp
commit 9228169d2ae055ed09a163887fc59a710a5eb73b upstream.
Concurrently changing driver mode and dynamic_epp with:
echo passive > /sys/devices/system/cpu/amd_pstate/status&
echo disable > /sys/devices/system/cpu/amd_pstate/dynamic_epp&
hits the WARN_ON_ONCE() in static_key_disable_cpuslocked() and hangs the
system since both sysfs writes are trying to do
amd_pstate_change_driver_mode() without any synchronization.
Grab the "amd_pstate_driver_lock" mutex when modifying "dynamic_epp" to
prevent the two paths from racing with each other. Add a lockdep
assertion for "amd_pstate_driver_lock" in
amd_pstate_change_driver_mode() to formalize the dependency.
Since "cppc_mode" is stable under "amd_pstate_driver_lock", only reload
the driver when in "AMD_PSTATE_ACTIVE" mode and reject all writes when
in passive or guided mode, or if the driver is not loaded, since only
active mode operates on EPP.
Fixes: e30ca6dd5345 ("cpufreq/amd-pstate: Add dynamic energy performance preference")
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
Link: https://lore.kernel.org/r/20260508051748.10484-2-kprateek.nayak@amd.com
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Hemanth Selam <Hemanth.Selam@amd.com>
Signed-off-by: mohanasv2 <mohanasv@amd.com>
…fied
commit c5eed6ddc757e477f52b3d99bfde9e59975c72ca upstream.
Writing the current "dynamic_epp" state to sysfs fails with -EINVAL even
though the desired result was achieved. Allow writes to "dynamic_epp"
that does not modify the state.
Fixes: e30ca6dd5345 ("cpufreq/amd-pstate: Add dynamic energy performance preference")
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
Link: https://lore.kernel.org/r/20260508051748.10484-4-kprateek.nayak@amd.com
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Hemanth Selam <Hemanth.Selam@amd.com>
Signed-off-by: mohanasv2 <mohanasv@amd.com>
commit f3acf7ff113007557538b278ccb0e4ab7ae513ea upstream.
An active power supply notifier can race with amd_pstate_epp_cpu_exit()
trying to reset the floor perf and can overwrite the floor perf set in
MSR_AMD_CPPC_REQ.
Unregister the notifier before setting the floor perf to prevent the
rare race.
Fixes: e30ca6dd5345 ("cpufreq/amd-pstate: Add dynamic energy performance preference")
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
Link: https://lore.kernel.org/r/20260508051748.10484-5-kprateek.nayak@amd.com
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Hemanth Selam <Hemanth.Selam@amd.com>
Signed-off-by: mohanasv2 <mohanasv@amd.com>
…is disabled
commit caa822d312be54e3fe1a3b52c887e0888e149c12 upstream.
If "dynamic_epp" is disabled, the driver initialization and the default
EPP selection from sysfs currently sets the EPP based on the power
supply state of the system at that time but there is no power supply
callbacks registered to toggle it when the power supply state changes.
This can lead to faster battery drain on platforms that start off while
being plugged to the wall but later move to battery power since the EPP
stays at AMD_CPPC_EPP_PERFORMANCE.
Use "epp_default_dc" as the default EPP selection when dynamic_epp is
disabled, restoring older behavior. On servers, this defaults to
AMD_CPPC_EPP_PERFORMANCE and on other platforms, it defaults to
AMD_CPPC_EPP_BALANCE_PERFORMANCE.
Fixes: e30ca6dd5345 ("cpufreq/amd-pstate: Add dynamic energy performance preference")
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
Link: https://lore.kernel.org/r/20260508051748.10484-6-kprateek.nayak@amd.com
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Hemanth Selam <Hemanth.Selam@amd.com>
Signed-off-by: mohanasv2 <mohanasv@amd.com>
commit f9f16835d4dc46113c0a72625ffbf61f1aa95e5c upstream.
Recent changes to the EPP unit test tries to perform a driver switch
with a cpufreq_policy reference held when the driver is loaded into
anything but the active mode which leads to a circular dependency and
the unit test hanging indefinitely.
Drop the reference before driver switch and grab it back once the driver
mode is stabilized for the test.
The EPP writes are only possible with CPUFREQ_POLICY_POWERSAVE policy.
Temporarily switch the cpudata->policy (while holding the write end of
the policy->rwsem) to CPUFREQ_POLICY_POWERSAVE and restore the original
policy once tests are done. To ensure the final EPP is correct in case
the driver started with CPUFREQ_POLICY_PERFORMANCE, EPP performance is
tested last.
The __free() based cleanup for cpufreq_policy is lost in the process.
Reported-by: Kalpana Shetty <kalpana.shetty@amd.com>
Fixes: 7e173bc310d2b ("cpufreq/amd-pstate-ut: Add a unit test for raw EPP")
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
Link: https://lore.kernel.org/r/20260508051748.10484-7-kprateek.nayak@amd.com
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Hemanth Selam <Hemanth.Selam@amd.com>
Signed-off-by: mohanasv2 <mohanasv@amd.com>
commit df488cac6140aa04ae52af9b4507d8f99a3762be upstream. Dan reported a possible NULL pointer dereference in amd-pstate-ut.c from static analysis and sure enough, running amd-pstate-ut in active mode with amd_dynamic_epp=enable results in a crash as a reult of the policy reference being set to NULL early, before disabling dynamic EPP. Kalpana also reported seeing amd-pstate-ut error out with -EBUSY for "amd_pstate_ut_epp" test when starting from the passive mode and amd_dynamic_epp=enable in the command line. The reason for the failure is that the command line enables dynamic_epp by default after the mode switch and the modifications to EPP values are blocked when running in dynamic EPP mode. Solution to both problems is to toggle off dynamic_epp *after* the mode switch when the driver grabs the policy reference again since the unit test is in full control of the policy after that point. The final restoration step will reset the dynamic_epp state via mode switch based on the initial conditions of the system. Reported-by: Kalpana Shetty <kalpana.shetty@amd.com> Reported-by: Dan Carpenter <error27@gmail.com> Closes: https://lore.kernel.org/linux-pm/ahEq0CvdBX0T7_cO@stanley.mountain/ Fixes: f9f16835d4dc ("cpufreq/amd-pstate-ut: Drop policy reference before driver switch") Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com> Link: https://patch.msgid.link/20260523055503.7651-1-kprateek.nayak@amd.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hemanth Selam <Hemanth.Selam@amd.com> Signed-off-by: mohanasv2 <mohanasv@amd.com>
commit 3cd07ee35a66038fd1a643632bfc057645e07c9a upstream.
Commit 4e16c1175238 ("cpufreq/amd-pstate: Stop caching EPP") removed
the epp_cached field from struct amd_cpudata in favour of always
reading from cppc_req_cached, but the kdoc above the struct still
documents @epp_cached.
Drop the now-stale @epp_cached entry.
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Fixes: 4e16c1175238 ("cpufreq/amd-pstate: Stop caching EPP")
Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
Link: https://lore.kernel.org/r/20260526022131.1302373-1-zhanxusheng@xiaomi.com
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Hemanth Selam <Hemanth.Selam@amd.com>
Signed-off-by: mohanasv2 <mohanasv@amd.com>
25345f1 to
b7d53f5
Compare
|
The PR has been updated with the proposed reduced patch set (188 patches total). Please help with the review. |
[ Upstream commit acd7df8d955480a6f6e5bb809da67b1500cc3cf4 ] tipc_sk_enqueue() runs with sk->sk_lock.slock held while the socket is owned by user context. The spinlock protects the backlog queue in this path, but it does not serialize against the socket owner consuming or purging sk_receive_queue. KASAN reported: CPU: 14 UID: 0 PID: 1050 Comm: tipc3 Not tainted 7.1.0-rc6+ #126 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x76/0xa0 lib/dump_stack.c:123 print_report+0xce/0x5b0 mm/kasan/report.c:482 kasan_report+0xc6/0x100 mm/kasan/report.c:597 __asan_report_load4_noabort+0x14/0x30 mm/kasan/report_generic.c:380 tipc_skb_dump+0x1327/0x16f0 net/tipc/trace.c:73 tipc_list_dump+0x208/0x2e0 net/tipc/trace.c:187 tipc_sk_dump+0xaf6/0xd60 net/tipc/socket.c:3996 trace_event_raw_event_tipc_sk_class+0x312/0x5a0 net/tipc/trace.h:188 tipc_sk_rcv+0xb1d/0x1d50 net/tipc/socket.c:2497 tipc_node_xmit+0x1c3/0x1440 net/tipc/node.c:1689 __tipc_sendmsg+0x97a/0x1440 net/tipc/socket.c:1512 tipc_sendmsg+0x52/0x80 net/tipc/socket.c:1400 sock_sendmsg+0x2f6/0x3e0 net/socket.c:825 splice_to_socket+0x7f9/0x1010 fs/splice.c:884 do_splice+0xe21/0x2330 fs/splice.c:936 __do_splice+0x153/0x260 fs/splice.c:1431 __x64_sys_splice+0x150/0x230 fs/splice.c:1616 x64_sys_call+0xeb5/0x2790 arch/x86/entry/syscall_64.c:41 do_syscall_64+0xf3/0x620 arch/x86/entry/syscall_64.c:63 entry_SYSCALL_64_after_hwframe+0x76/0x7e arch/x86/entry/entry_64.S:130 RIP: 0033:0x71624e8aafe2 Code: 08 0f 85 71 3a ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 RSP: 002b:0000716157ffed68 EFLAGS: 00000246 ORIG_RAX: 0000000000000113 RAX: ffffffffffffffda RBX: 0000716157fff6c0 RCX: 000071624e8aafe2 RDX: 000000000000005f RSI: 0000000000000000 RDI: 0000000000000066 RBP: 0000716157ffed90 R08: 0000000000008000 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffff00 R13: 0000000000000021 R14: 0000000000000000 R15: 00007fff89799c40 </TASK> The TIPC_DUMP_ALL tracepoints in tipc_sk_enqueue() also dump sk_receive_queue and can therefore dereference skbs that the socket owner has already dequeued or freed. Restrict these dumps to TIPC_DUMP_SK_BKLGQ, which matches the queue protected by the held spinlock. Keep the change limited to the enqueue path, where the unsafe queue dump is reachable while the socket is owned by user context. Fixes: 01e661e ("tipc: add trace_events for tipc socket") Cc: stable@vger.kernel.org Signed-off-by: Li Xiasong <lixiasong1@huawei.com> Reviewed-by: Tung Nguyen <tung.quang.nguyen@est.tech> Link: https://patch.msgid.link/20260611135647.3666727-1-lixiasong1@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
Thanks for your work, this PR has merged. |
18 participants
AMD Venice CPPC (FAST) support for VeLinux 6.6 kernel
Patch List:
amd_pstate_hw_prefcoreamd_pstate_prefcore_rankingcppc_cap1_cachedPatch Series Overview:
This patch series consists of 188 upstream commits backporting AMD P-state and CPPC (Collaborative Processor Performance Control) enhancements into the veLinux 6.6-velinux kernel, on branch
Venice_CPPC_patches. The changes span the core amd-pstate driver, the amd-pstate-ut unit test framework, x86 CPU feature and scheduler-topology infrastructure, the cpufreq core, ACPI CPPC preferred-core detection, and documentation.Key Bug Fixes:
min_limit_perfand the corresponding frequency not being updated correctly when the performance governor is active.CPPC.min_perfin active mode under the performance governor.cpufreq_cpu_put().max_perfnot being updated correctly under the schedutil governor, holding the frequency ceiling below the hardware maximum.policy->boost_enabledbeing left incorrect when the boost update path failed partway through.max_perfwas compared against a frequency in different units, causing incorrect frequency caps.CPPC.max_perffrom exceeding nominal performance when Core Performance Boost is disabled.retinamd_pstate_ut_check_driver().Feature Additions:
trace_amd_pstate_cppc_req2()tracepoint andfloor_freq/floor_countsysfs attributes.X86_FEATUREbit (CPUID 0x80000007:EDX[16]) that gates FLOOR_PERF availability.amd_pstate_epp=kernel command-line override.X86_FEATURE_AMD_WORKLOAD_CLASSbit and disabled preferred cores on designs with workload classification.Logic & Performance Improvements:
driver_lockuses withguard(mutex)/scoped cleanup, removed unnecessary locks inset_boostandupdate_limits, and converted policy reference handling to scope-based cleanup.amd_cpudata, improving cache locality and making value relationships explicit.u32tou8, matching the hardware register width.amd_cpudatato kHz, eliminating mixed Hz/kHz confusion.FIELD_PREP()/FIELD_GET()using proper bitmask definitions; addedFIELD_MODIFY()helper.cppc_req_cachedhandling across MSR and shared-memory paths, with correct invalidation on suspend and updates in the fast_switch case.epp_cachedvariable, relying oncppc_req_cachedfor EPP state.boost_supportedrelative to the enable call.amd_get_highest_perf()into a single function incppc.c, moving it out of the driver into shared x86 AMD code.adjust_perf()andupdate_limits(), split and consolidatedcpufreq_online(), added locking guards, and madeexit()return void.arch_init_invariance_cppc()later, clearedhybrid_max_perf_cpubefore driver registration, and rearranged intel_pstate asym-capacity locking / declarations.Unit Test Framework (amd-pstate-ut):
_free-based policy cleanup, min-freq unit conversion, and dynamic_epp/policy-reference handling around mode switches.Documentation:
amd_pstate_prefcore_ranking/amd_pstate_hw_prefcoresysfs files.amd_pstate_floor_freqandamd_pstate_floor_countsysfs attributes.struct amd_cpudata.Unit Test:
1. Mode gate:
2. DUT facts:
3. Driver bring-up + crash scan:
4. CPPC frequency calculation:
5. CPPC MSR decode:
6. Governor / EPP availability:
7. EPP → MSR_AMD_CPPC_REQ[31:24] mapping:
8. Frequency response under load:
9. FLOOR_PERF feature gate:
10. floor_freq range validation:
11. Floor latches in HW (control plane):
12. HIGH/LOW floor sweep — reduced-patch impact check:
13. Persistence across offline/online:
14: amd-pstate-ut (safe subset):