Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39 |
|
#
1cd04adf |
| 12-Jul-2023 |
Yangtao Li <frank.li@vivo.com> |
cpufreq: acpi: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error
cpufreq: acpi: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void.
Trivially convert this driver from always returning zero in the remove callback to the void returning variant.
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Yangtao Li <frank.li@vivo.com> Acked-by: Rafael J. Wysocki <rafael@kernel.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
show more ...
|
Revision tags: v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28 |
|
#
73c7f824 |
| 11-May-2023 |
Petr Pavlu <petr.pavlu@suse.com> |
cpufreq: ACPI: Prevent a warning when another frequency driver is loaded
The recent change to use platform devices to load ACPI PPC and PCC drivers caused that a misleading warning is reported when
cpufreq: ACPI: Prevent a warning when another frequency driver is loaded
The recent change to use platform devices to load ACPI PPC and PCC drivers caused that a misleading warning is reported when a respective module cannot be loaded because another CPU frequency driver is already registered:
kernel: acpi-cpufreq: probe of acpi-cpufreq failed with error -17
Address it by changing the return code in acpi-cpufreq and pcc-cpufreq for this case from -EEXIST to -ENODEV which silences the warning in call_driver_probe().
The change has also a benefit for users of init_module() as this return code is propagated out from the syscall. The previous -EEXIST code made the callers, such as kmod, wrongly believe that the module was already loaded instead of that it failed to load.
Fixes: 691a63712347 ("ACPI: cpufreq: Use platform devices to load ACPI PPC and PCC drivers") Reported-by: Kevin Locke <kevin@kevinlocke.name> Link: https://lore.kernel.org/lkml/ZFreh8SDMX67EaB6@kevinlocke.name/ Signed-off-by: Petr Pavlu <petr.pavlu@suse.com> Tested-by: Kevin Locke <kevin@kevinlocke.name> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20 |
|
#
691a6371 |
| 16-Mar-2023 |
Petr Pavlu <petr.pavlu@suse.com> |
ACPI: cpufreq: Use platform devices to load ACPI PPC and PCC drivers
The acpi-cpufreq and pcc-cpufreq drivers are loaded through per-CPU module aliases. This can result in many unnecessary load requ
ACPI: cpufreq: Use platform devices to load ACPI PPC and PCC drivers
The acpi-cpufreq and pcc-cpufreq drivers are loaded through per-CPU module aliases. This can result in many unnecessary load requests during boot if another frequency module, such as intel_pstate, is already active. For instance, on a typical Intel system, one can observe that udev makes 2x#CPUs attempts to insert acpi_cpufreq and 1x#CPUs attempts for pcc_cpufreq. All these tries then fail if another frequency module is already registered.
In the worst case, without the recent fix in commit 0254127ab977e ("module: Don't wait for GOING modules"), these module loads occupied all udev workers and had their initialization attempts ran sequentially. Resolving all these loads then on some larger machines took too long, prevented other hardware from getting its drivers initialized and resulted in a failed boot. Discussion over these duplicate module requests ended up with a conclusion that only one load attempt should be ideally made.
Both acpi-cpufreq and pcc-cpufreq drivers use platform firmware controls which are defined by ACPI. It is possible to treat these interfaces as platform devices.
The patch extends the ACPI parsing logic to check the ACPI namespace if the PPC or PCC interface is present and creates a virtual platform device for each if it is available. The acpi-cpufreq and pcc-cpufreq drivers are then updated to map to these devices.
This allows to try loading acpi-cpufreq and pcc-cpufreq only once during boot and only if a given interface is available in the firmware.
Signed-off-by: Petr Pavlu <petr.pavlu@suse.com> [ rjw: whitespace and error message log level adjustments, subject edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12 |
|
#
44204632 |
| 05-Dec-2022 |
Stuart Hayes <stuart.w.hayes@gmail.com> |
cpufreq: ACPI: Only set boost MSRs on supported CPUs
Stop trying to set boost MSRs on CPUs that don't support boost.
This corrects a bug in the recent patch "Defer setting boost MSRs".
Fixes: 13fd
cpufreq: ACPI: Only set boost MSRs on supported CPUs
Stop trying to set boost MSRs on CPUs that don't support boost.
This corrects a bug in the recent patch "Defer setting boost MSRs".
Fixes: 13fdbc8b8da6 ("cpufreq: ACPI: Defer setting boost MSRs") Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com> Reported-by: Borislav Petkov (AMD) <bp@alien8.de> Tested-by: Borislav Petkov (AMD) <bp@alien8.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78 |
|
#
cab75e1c |
| 08-Nov-2022 |
Nathan Chancellor <nathan@kernel.org> |
cpufreq: ACPI: Remove unused variables 'acpi_cpufreq_online' and 'ret'
Clang warns:
drivers/cpufreq/acpi-cpufreq.c:970:24: error: variable 'ret' is uninitialized when used here [-Werror,-Wuniniti
cpufreq: ACPI: Remove unused variables 'acpi_cpufreq_online' and 'ret'
Clang warns:
drivers/cpufreq/acpi-cpufreq.c:970:24: error: variable 'ret' is uninitialized when used here [-Werror,-Wuninitialized] acpi_cpufreq_online = ret; ^~~ drivers/cpufreq/acpi-cpufreq.c:960:9: note: initialize the variable 'ret' to silence this warning int ret; ^ = 0 1 error generated.
Both ret and acpi_cpufreq_online are now unused so they can be safely removed, clearing up the warning.
Fixes: 13fdbc8b8da6 ("cpufreq: ACPI: Defer setting boost MSRs") Link: https://github.com/ClangBuiltLinux/linux/issues/1757 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v6.0.7, v5.15.77 |
|
#
13fdbc8b |
| 02-Nov-2022 |
Stuart Hayes <stuart.w.hayes@gmail.com> |
cpufreq: ACPI: Defer setting boost MSRs
When acpi-cpufreq is loaded, boost is enabled on every CPU (by setting an MSR) before the driver is registered with cpufreq. This can be very time consuming,
cpufreq: ACPI: Defer setting boost MSRs
When acpi-cpufreq is loaded, boost is enabled on every CPU (by setting an MSR) before the driver is registered with cpufreq. This can be very time consuming, because it is done with a CPU hotplug startup callback, and cpuhp_setup_state() schedules the callback (cpufreq_boost_online()) to run on each CPU one at a time, waiting for each to run before calling the next.
If cpufreq_register_driver() fails--if, for example, there are no ACPI P-states present--this is wasted time.
Since cpufreq already sets up a CPU hotplug startup callback if and when acpi-cpufreq is registered, set the boost MSRs in acpi_cpufreq_cpu_init(), which is called by the cpufreq cpuhp callback. This allows acpi-cpufreq to exit quickly if it is loaded but not needed.
On one system with 192 CPUs, this patch speeds up boot by about 30 seconds.
Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1 |
|
#
abdea5fc |
| 08-Oct-2022 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
cpufreq: ACPI: Use str_enabled_disabled() helper
Use str_enabled_disabled() helper instead of open coding the same.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
cpufreq: ACPI: Use str_enabled_disabled() helper
Use str_enabled_disabled() helper instead of open coding the same.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50 |
|
#
d6f89596 |
| 22-Jun-2022 |
Tony W Wang-oc <TonyWWang-oc@zhaoxin.com> |
cpufreq: ACPI: Add Zhaoxin/Centaur turbo boost control interface support
Recent Zhaoxin/Centaur CPUs support X86_FEATURE_IDA and the turbo boost can be dynamically enabled or disabled through MSR 0x
cpufreq: ACPI: Add Zhaoxin/Centaur turbo boost control interface support
Recent Zhaoxin/Centaur CPUs support X86_FEATURE_IDA and the turbo boost can be dynamically enabled or disabled through MSR 0x1a0[38] in the same way as Intel. So add turbo boost control support for these CPUs too.
Signed-off-by: Tony W Wang-oc <TonyWWang-oc@zhaoxin.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64 |
|
#
1f39fa0d |
| 08-Sep-2021 |
Vincent Donnefort <vincent.donnefort@arm.com> |
cpufreq: Introducing CPUFREQ_RELATION_E
This newly introduced flag can be applied by a governor to a CPUFreq relation, when looking for a frequency within the policy table. The resolution would then
cpufreq: Introducing CPUFREQ_RELATION_E
This newly introduced flag can be applied by a governor to a CPUFreq relation, when looking for a frequency within the policy table. The resolution would then only walk through efficient frequencies.
Even with the flag set, the policy max limit will still be honoured. If no efficient frequencies can be found within the limits of the policy, an inefficient one would be returned.
Signed-off-by: Vincent Donnefort <vincent.donnefort@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.14.2, v5.10.63, v5.14.1, v5.10.62 |
|
#
692a3b9a |
| 01-Sep-2021 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: acpi: Remove acpi_cpufreq_cpu_ready()
The ready() callback was implemented earlier for acpi-cpufreq driver as we wanted to use policy->cpuinfo.max_freq for which the policy was required to
cpufreq: acpi: Remove acpi_cpufreq_cpu_ready()
The ready() callback was implemented earlier for acpi-cpufreq driver as we wanted to use policy->cpuinfo.max_freq for which the policy was required to be verified.
That is no longer the case and we can do the pr_warn() right from ->init() callback now. Remove acpi_cpufreq_cpu_ready().
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.14, v5.10.61, v5.10.60 |
|
#
09681a07 |
| 03-Aug-2021 |
Sebastian Andrzej Siewior <bigeasy@linutronix.de> |
cpufreq: Replace deprecated CPU-hotplug functions
The functions get_online_cpus() and put_online_cpus() have been deprecated during the CPU hotplug rework. They map directly to cpus_read_lock() and
cpufreq: Replace deprecated CPU-hotplug functions
The functions get_online_cpus() and put_online_cpus() have been deprecated during the CPU hotplug rework. They map directly to cpus_read_lock() and cpus_read_unlock().
Replace deprecated CPU-hotplug functions with the official version. The behavior remains unchanged.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12 |
|
#
3743d55b |
| 25-Apr-2021 |
Huang Rui <ray.huang@amd.com> |
x86, sched: Fix the AMD CPPC maximum performance value on certain AMD Ryzen generations
Some AMD Ryzen generations has different calculation method on maximum performance. 255 is not for all ASICs,
x86, sched: Fix the AMD CPPC maximum performance value on certain AMD Ryzen generations
Some AMD Ryzen generations has different calculation method on maximum performance. 255 is not for all ASICs, some specific generations should use 166 as the maximum performance. Otherwise, it will report incorrect frequency value like below:
~ → lscpu | grep MHz CPU MHz: 3400.000 CPU max MHz: 7228.3198 CPU min MHz: 2200.0000
[ mingo: Tidied up whitespace use. ] [ Alexander Monakov <amonakov@ispras.ru>: fix 225 -> 255 typo. ]
Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD systems") Fixes: 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost frequencies") Reported-by: Jason Bagavatsingham <jason.bagavatsingham@gmail.com> Fixed-by: Alexander Monakov <amonakov@ispras.ru> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Tested-by: Jason Bagavatsingham <jason.bagavatsingham@gmail.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210425073451.2557394-1-ray.huang@amd.com Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=211791 Signed-off-by: Ingo Molnar <mingo@kernel.org>
show more ...
|
Revision tags: v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17 |
|
#
538b0188 |
| 15-Feb-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
cpufreq: ACPI: Set cpuinfo.max_freq directly if max boost is known
Commit 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost frequencies") attempted to address a performance issue
cpufreq: ACPI: Set cpuinfo.max_freq directly if max boost is known
Commit 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost frequencies") attempted to address a performance issue involving acpi-cpufreq, the schedutil governor and scale-invariance on x86 by extending the frequency tables created by acpi-cpufreq to cover the entire range of "turbo" (or "boost") frequencies, but that caused frequencies reported via /proc/cpuinfo and the scaling_cur_freq attribute in sysfs to change which may confuse users and monitoring tools.
For this reason, revert the part of commit 3c55e94c0ade adding the extra entry to the frequency table and use the observation that in principle cpuinfo.max_freq need not be equal to the maximum frequency listed in the frequency table for the given policy.
Namely, modify cpufreq_frequency_table_cpuinfo() to allow cpufreq drivers to set their own cpuinfo.max_freq above that frequency and change acpi-cpufreq to set cpuinfo.max_freq to the maximum boost frequency found via CPPC.
This should be sufficient to let all of the cpufreq subsystem know the real maximum frequency of the CPU without changing frequency reporting.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=211305 Fixes: 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost frequencies") Reported-by: Matt McDonald <gardotd426@gmail.com> Tested-by: Matt McDonald <gardotd426@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Giovanni Gherdovich <ggherdovich@suse.cz> Tested-by: Michael Larabel <Michael@phoronix.com> Cc: 5.11+ <stable@vger.kernel.org> # 5.11+
show more ...
|
Revision tags: v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
d11a1d08 |
| 04-Feb-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
cpufreq: ACPI: Update arch scale-invariance max perf ratio if CPPC is not there
If the maximum performance level taken for computing the arch_max_freq_ratio value used in the x86 scale-invariance co
cpufreq: ACPI: Update arch scale-invariance max perf ratio if CPPC is not there
If the maximum performance level taken for computing the arch_max_freq_ratio value used in the x86 scale-invariance code is higher than the one corresponding to the cpuinfo.max_freq value coming from the acpi_cpufreq driver, the scale-invariant utilization falls below 100% even if the CPU runs at cpuinfo.max_freq or slightly faster, which causes the schedutil governor to select a frequency below cpuinfo.max_freq. That frequency corresponds to a frequency table entry below the maximum performance level necessary to get to the "boost" range of CPU frequencies which prevents "boost" frequencies from being used in some workloads.
While this issue is related to scale-invariance, it may be amplified by commit db865272d9c4 ("cpufreq: Avoid configuring old governors as default with intel_pstate") from the 5.10 development cycle which made it extremely easy to default to schedutil even if the preferred driver is acpi_cpufreq as long as intel_pstate is built too, because the mere presence of the latter effectively removes the ondemand governor from the defaults. Distro kernels are likely to include both intel_pstate and acpi_cpufreq on x86, so their users who cannot use intel_pstate or choose to use acpi_cpufreq may easily be affectecd by this issue.
If CPPC is available, it can be used to address this issue by extending the frequency tables created by acpi_cpufreq to cover the entire available frequency range (including "boost" frequencies) for each CPU, but if CPPC is not there, acpi_cpufreq has no idea what the maximum "boost" frequency is and the frequency tables created by it cannot be extended in a meaningful way, so in that case make it ask the arch scale-invariance code to to use the "nominal" performance level for CPU utilization scaling in order to avoid the issue at hand.
Fixes: db865272d9c4 ("cpufreq: Avoid configuring old governors as default with intel_pstate") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Giovanni Gherdovich <ggherdovich@suse.cz> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
show more ...
|
#
3c55e94c |
| 04-Feb-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
cpufreq: ACPI: Extend frequency tables to cover boost frequencies
A severe performance regression on AMD EPYC processors when using the schedutil scaling governor was discovered by Phoronix.com and
cpufreq: ACPI: Extend frequency tables to cover boost frequencies
A severe performance regression on AMD EPYC processors when using the schedutil scaling governor was discovered by Phoronix.com and attributed to the following commits:
41ea667227ba ("x86, sched: Calculate frequency invariance for AMD systems")
976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P for frequency invariance on AMD EPYC")
The source of the problem is that the maximum performance level taken for computing the arch_max_freq_ratio value used in the x86 scale- invariance code is higher than the one corresponding to the cpuinfo.max_freq value coming from the acpi_cpufreq driver.
This effectively causes the scale-invariant utilization to fall below 100% even if the CPU runs at cpuinfo.max_freq or slightly faster, so the schedutil governor selects a frequency below cpuinfo.max_freq then. That frequency corresponds to a frequency table entry below the maximum performance level necessary to get to the "boost" range of CPU frequencies.
However, if the cpuinfo.max_freq value coming from acpi_cpufreq was higher, the schedutil governor would select higher frequencies which in turn would allow acpi_cpufreq to set more adequate performance levels and to get to the "boost" range of CPU frequencies more often.
This issue affects any systems where acpi_cpufreq is used and the "boost" (or "turbo") frequencies are enabled, not just AMD EPYC. Moreover, commit db865272d9c4 ("cpufreq: Avoid configuring old governors as default with intel_pstate") from the 5.10 development cycle made it extremely easy to default to schedutil even if the preferred driver is acpi_cpufreq as long as intel_pstate is built too, because the mere presence of the latter effectively removes the ondemand governor from the defaults. Distro kernels are likely to include both intel_pstate and acpi_cpufreq on x86, so their users who cannot use intel_pstate or choose to use acpi_cpufreq may easily be affectecd by this issue.
To address this issue, extend the frequency table constructed by acpi_cpufreq for each CPU to cover the entire range of available frequencies (including the "boost" ones) if CPPC is available and indicates that "boost" (or "turbo") frequencies are enabled. That causes cpuinfo.max_freq to become the maximum "boost" frequency of the given CPU (instead of the maximum frequency returned by the ACPI _PSS object that corresponds to the "nominal" performance level).
Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD systems") Fixes: 976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P for frequency invariance on AMD EPYC") Fixes: db865272d9c4 ("cpufreq: Avoid configuring old governors as default with intel_pstate") Link: https://www.phoronix.com/scan.php?page=article&item=linux511-amd-schedutil&num=1 Link: https://lore.kernel.org/linux-pm/20210203135321.12253-2-ggherdovich@suse.cz/ Reported-by: Michael Larabel <Michael@phoronix.com> Diagnosed-by: Giovanni Gherdovich <ggherdovich@suse.cz> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Giovanni Gherdovich <ggherdovich@suse.cz> Reviewed-by: Giovanni Gherdovich <ggherdovich@suse.cz> Tested-by: Michael Larabel <Michael@phoronix.com>
show more ...
|
#
0a5fcc0a |
| 15-Feb-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
cpufreq: ACPI: Set cpuinfo.max_freq directly if max boost is known
commit 538b0188da4653b9f4511a114f014354fb6fb7a5 upstream.
Commit 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover bo
cpufreq: ACPI: Set cpuinfo.max_freq directly if max boost is known
commit 538b0188da4653b9f4511a114f014354fb6fb7a5 upstream.
Commit 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost frequencies") attempted to address a performance issue involving acpi-cpufreq, the schedutil governor and scale-invariance on x86 by extending the frequency tables created by acpi-cpufreq to cover the entire range of "turbo" (or "boost") frequencies, but that caused frequencies reported via /proc/cpuinfo and the scaling_cur_freq attribute in sysfs to change which may confuse users and monitoring tools.
For this reason, revert the part of commit 3c55e94c0ade adding the extra entry to the frequency table and use the observation that in principle cpuinfo.max_freq need not be equal to the maximum frequency listed in the frequency table for the given policy.
Namely, modify cpufreq_frequency_table_cpuinfo() to allow cpufreq drivers to set their own cpuinfo.max_freq above that frequency and change acpi-cpufreq to set cpuinfo.max_freq to the maximum boost frequency found via CPPC.
This should be sufficient to let all of the cpufreq subsystem know the real maximum frequency of the CPU without changing frequency reporting.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=211305 Fixes: 3c55e94c0ade ("cpufreq: ACPI: Extend frequency tables to cover boost frequencies") Reported-by: Matt McDonald <gardotd426@gmail.com> Tested-by: Matt McDonald <gardotd426@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Giovanni Gherdovich <ggherdovich@suse.cz> Tested-by: Michael Larabel <Michael@phoronix.com> Cc: 5.11+ <stable@vger.kernel.org> # 5.11+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
18193e09 |
| 04-Feb-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
cpufreq: ACPI: Update arch scale-invariance max perf ratio if CPPC is not there
commit d11a1d08a082a7dc0ada423d2b2e26e9b6f2525c upstream.
If the maximum performance level taken for computing the ar
cpufreq: ACPI: Update arch scale-invariance max perf ratio if CPPC is not there
commit d11a1d08a082a7dc0ada423d2b2e26e9b6f2525c upstream.
If the maximum performance level taken for computing the arch_max_freq_ratio value used in the x86 scale-invariance code is higher than the one corresponding to the cpuinfo.max_freq value coming from the acpi_cpufreq driver, the scale-invariant utilization falls below 100% even if the CPU runs at cpuinfo.max_freq or slightly faster, which causes the schedutil governor to select a frequency below cpuinfo.max_freq. That frequency corresponds to a frequency table entry below the maximum performance level necessary to get to the "boost" range of CPU frequencies which prevents "boost" frequencies from being used in some workloads.
While this issue is related to scale-invariance, it may be amplified by commit db865272d9c4 ("cpufreq: Avoid configuring old governors as default with intel_pstate") from the 5.10 development cycle which made it extremely easy to default to schedutil even if the preferred driver is acpi_cpufreq as long as intel_pstate is built too, because the mere presence of the latter effectively removes the ondemand governor from the defaults. Distro kernels are likely to include both intel_pstate and acpi_cpufreq on x86, so their users who cannot use intel_pstate or choose to use acpi_cpufreq may easily be affectecd by this issue.
If CPPC is available, it can be used to address this issue by extending the frequency tables created by acpi_cpufreq to cover the entire available frequency range (including "boost" frequencies) for each CPU, but if CPPC is not there, acpi_cpufreq has no idea what the maximum "boost" frequency is and the frequency tables created by it cannot be extended in a meaningful way, so in that case make it ask the arch scale-invariance code to to use the "nominal" performance level for CPU utilization scaling in order to avoid the issue at hand.
Fixes: db865272d9c4 ("cpufreq: Avoid configuring old governors as default with intel_pstate") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Giovanni Gherdovich <ggherdovich@suse.cz> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
8a3fc32b |
| 04-Feb-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
cpufreq: ACPI: Extend frequency tables to cover boost frequencies
commit 3c55e94c0adea4a5389c4b80f6ae9927dd6a4501 upstream.
A severe performance regression on AMD EPYC processors when using the sch
cpufreq: ACPI: Extend frequency tables to cover boost frequencies
commit 3c55e94c0adea4a5389c4b80f6ae9927dd6a4501 upstream.
A severe performance regression on AMD EPYC processors when using the schedutil scaling governor was discovered by Phoronix.com and attributed to the following commits:
41ea667227ba ("x86, sched: Calculate frequency invariance for AMD systems")
976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P for frequency invariance on AMD EPYC")
The source of the problem is that the maximum performance level taken for computing the arch_max_freq_ratio value used in the x86 scale- invariance code is higher than the one corresponding to the cpuinfo.max_freq value coming from the acpi_cpufreq driver.
This effectively causes the scale-invariant utilization to fall below 100% even if the CPU runs at cpuinfo.max_freq or slightly faster, so the schedutil governor selects a frequency below cpuinfo.max_freq then. That frequency corresponds to a frequency table entry below the maximum performance level necessary to get to the "boost" range of CPU frequencies.
However, if the cpuinfo.max_freq value coming from acpi_cpufreq was higher, the schedutil governor would select higher frequencies which in turn would allow acpi_cpufreq to set more adequate performance levels and to get to the "boost" range of CPU frequencies more often.
This issue affects any systems where acpi_cpufreq is used and the "boost" (or "turbo") frequencies are enabled, not just AMD EPYC. Moreover, commit db865272d9c4 ("cpufreq: Avoid configuring old governors as default with intel_pstate") from the 5.10 development cycle made it extremely easy to default to schedutil even if the preferred driver is acpi_cpufreq as long as intel_pstate is built too, because the mere presence of the latter effectively removes the ondemand governor from the defaults. Distro kernels are likely to include both intel_pstate and acpi_cpufreq on x86, so their users who cannot use intel_pstate or choose to use acpi_cpufreq may easily be affectecd by this issue.
To address this issue, extend the frequency table constructed by acpi_cpufreq for each CPU to cover the entire range of available frequencies (including the "boost" ones) if CPPC is available and indicates that "boost" (or "turbo") frequencies are enabled. That causes cpuinfo.max_freq to become the maximum "boost" frequency of the given CPU (instead of the maximum frequency returned by the ACPI _PSS object that corresponds to the "nominal" performance level).
Fixes: 41ea667227ba ("x86, sched: Calculate frequency invariance for AMD systems") Fixes: 976df7e5730e ("x86, sched: Use midpoint of max_boost and max_P for frequency invariance on AMD EPYC") Fixes: db865272d9c4 ("cpufreq: Avoid configuring old governors as default with intel_pstate") Link: https://www.phoronix.com/scan.php?page=article&item=linux511-amd-schedutil&num=1 Link: https://lore.kernel.org/linux-pm/20210203135321.12253-2-ggherdovich@suse.cz/ Reported-by: Michael Larabel <Michael@phoronix.com> Diagnosed-by: Giovanni Gherdovich <ggherdovich@suse.cz> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Giovanni Gherdovich <ggherdovich@suse.cz> Reviewed-by: Giovanni Gherdovich <ggherdovich@suse.cz> Tested-by: Michael Larabel <Michael@phoronix.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.10, v5.8.17 |
|
#
5368512a |
| 18-Oct-2020 |
Wei Huang <wei.huang2@amd.com> |
acpi-cpufreq: Honor _PSD table setting on new AMD CPUs
acpi-cpufreq has a old quirk that overrides the _PSD table supplied by BIOS on AMD CPUs. However the _PSD table of new AMD CPUs (Family 19h+) n
acpi-cpufreq: Honor _PSD table setting on new AMD CPUs
acpi-cpufreq has a old quirk that overrides the _PSD table supplied by BIOS on AMD CPUs. However the _PSD table of new AMD CPUs (Family 19h+) now accurately reports the P-state dependency of CPU cores. Hence this quirk needs to be fixed in order to support new CPUs' frequency control.
Fixes: acd316248205 ("acpi-cpufreq: Add quirk to disable _PSD usage on all AMD CPUs") Signed-off-by: Wei Huang <wei.huang2@amd.com> [ rjw: Subject edit ] Cc: 3.10+ <stable@vger.kernel.org> # 3.10+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9 |
|
#
a7b90937 |
| 15-Jul-2020 |
Lee Jones <lee.jones@linaro.org> |
cpufreq: acpi-cpufreq: Mark sometimes used ID structs as __maybe_unused
Not used when MODULE is not defined.
Fixes the following W=1 kernel build warning(s):
drivers/cpufreq/acpi-cpufreq.c:1004:3
cpufreq: acpi-cpufreq: Mark sometimes used ID structs as __maybe_unused
Not used when MODULE is not defined.
Fixes the following W=1 kernel build warning(s):
drivers/cpufreq/acpi-cpufreq.c:1004:36: warning: ‘processor_device_ids’ defined but not used [-Wunused-const-variable=] 997 | static const struct x86_cpu_id acpi_cpufreq_ids[] = { | ^~~~~~~~~~~~~~~~ drivers/cpufreq/acpi-cpufreq.c:997:32: warning: ‘acpi_cpufreq_ids’ defined but not used [-Wunused-const-variable=] 619 | static const struct acpi_device_id processor_device_ids[] = { | ^~~~~~~~~~~~~~~~~~~~
Signed-off-by: Lee Jones <lee.jones@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
e1711f29 |
| 15-Jul-2020 |
Lee Jones <lee.jones@linaro.org> |
cpufreq: acpi-cpufreq: Mark 'dummy' variable as __always_unused
If we fail to use a variable, even a 'dummy' one, then the compiler complains that it is set but not used. We know this is fine, so w
cpufreq: acpi-cpufreq: Mark 'dummy' variable as __always_unused
If we fail to use a variable, even a 'dummy' one, then the compiler complains that it is set but not used. We know this is fine, so we set it as __always_unused to let the compiler know.
Fixes the following W=1 kernel build warning(s):
drivers/cpufreq/acpi-cpufreq.c: In function ‘cpu_freq_read_intel’: drivers/cpufreq/acpi-cpufreq.c:247:11: warning: variable ‘dummy’ set but not used [-Wunused-but-set-variable] drivers/cpufreq/acpi-cpufreq.c: In function ‘cpu_freq_read_amd’: drivers/cpufreq/acpi-cpufreq.c:265:11: warning: variable ‘dummy’ set but not used [-Wunused-but-set-variable]
Signed-off-by: Lee Jones <lee.jones@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
8479eb82 |
| 13-Jul-2020 |
Alexander A. Klimov <grandmaster@al2klimov.de> |
cpufreq: Replace HTTP links with HTTPS ones
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate.
Deterministic algorithm: For e
cpufreq: Replace HTTP links with HTTPS ones
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate.
Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7 |
|
#
cf6fada7 |
| 29-May-2020 |
Xiongfeng Wang <wangxiongfeng2@huawei.com> |
cpufreq: change '.set_boost' to act on one policy
Macro 'for_each_active_policy()' is defined internally. To avoid some cpufreq driver needing this macro to iterate over all the policies in '.set_bo
cpufreq: change '.set_boost' to act on one policy
Macro 'for_each_active_policy()' is defined internally. To avoid some cpufreq driver needing this macro to iterate over all the policies in '.set_boost' callback, we redefine '.set_boost' to act on only one policy and pass the policy as an argument.
'cpufreq_boost_trigger_state()' iterates over all the policies to set boost for the system.
This is preparation for adding SW BOOST support for CPPC.
To protect Boost enable/disable by sysfs from CPU online/offline, add 'cpu_hotplug_lock' before calling '.set_boost' for each CPU.
Also move the lock from 'set_boost()' to 'store_cpb()' in acpi_cpufreq.
Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> Suggested-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> [ rjw: Subject & changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28 |
|
#
b11d77fa |
| 24-Mar-2020 |
Thomas Gleixner <tglx@linutronix.de> |
cpufreq: Convert to new X86 CPU match macros
The new macro set has a consistent namespace and uses C99 initializers instead of the grufty C89 ones.
Get rid the of most local macro wrappers for cons
cpufreq: Convert to new X86 CPU match macros
The new macro set has a consistent namespace and uses C99 initializers instead of the grufty C89 ones.
Get rid the of most local macro wrappers for consistency. The ones which make sense for readability are renamed to X86_MATCH*.
In the centrino driver this also removes the two extra duplicates of family 6 model 13 which have no value at all.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lkml.kernel.org/r/87eetheu88.fsf@nanos.tec.linutronix.de
show more ...
|
Revision tags: v5.4.27 |
|
#
ba5bade4 |
| 20-Mar-2020 |
Thomas Gleixner <tglx@linutronix.de> |
x86/devicetable: Move x86 specific macro out of generic code
There is no reason that this gunk is in a generic header file. The wildcard defines need to stay as they are required by file2alias.
Sig
x86/devicetable: Move x86 specific macro out of generic code
There is no reason that this gunk is in a generic header file. The wildcard defines need to stay as they are required by file2alias.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lkml.kernel.org/r/20200320131508.736205164@linutronix.de
show more ...
|