#
f4fd3797 |
| 27-Jun-2013 |
Lan Tianyu <tianyu.lan@intel.com> |
acpi-cpufreq: Add new sysfs attribute freqdomain_cpus
Commits fcf8058 (cpufreq: Simplify cpufreq_add_dev()) and aa77a52 (cpufreq: acpi-cpufreq: Don't set policy->related_cpus from .init()) changed t
acpi-cpufreq: Add new sysfs attribute freqdomain_cpus
Commits fcf8058 (cpufreq: Simplify cpufreq_add_dev()) and aa77a52 (cpufreq: acpi-cpufreq: Don't set policy->related_cpus from .init()) changed the contents of the "related_cpus" sysfs attribute on systems where acpi-cpufreq is used and user space can't get the list of CPUs which are in the same hardware coordination CPU domain (provided by the ACPI AML method _PSD) via "related_cpus" any more.
To make up for that loss add a new sysfs attribute "freqdomian_cpus" for the acpi-cpufreq driver which exposes the list of CPUs in the same domain regardless of whether it is coordinated by hardware or software.
[rjw: Changelog, documentation] References: https://bugzilla.kernel.org/show_bug.cgi?id=58761 Reported-by: Jean-Philippe Halimi <jean-philippe.halimi@exascale-computing.eu> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
e15d8309 |
| 19-Jun-2013 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: ACPI: call CPUFREQ_POSTCHANGE notfier in error cases
PRECHANGE and POSTCHANGE notifiers must be called in groups, i.e either both should be called or both shouldn't be.
In case we have sta
cpufreq: ACPI: call CPUFREQ_POSTCHANGE notfier in error cases
PRECHANGE and POSTCHANGE notifiers must be called in groups, i.e either both should be called or both shouldn't be.
In case we have started PRECHANGE notifier and found an error, we must call POSTCHANGE notifier with freqs.new = freqs.old to guarantee that the sequence of calling notifiers is complete.
This patch fixes it.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
c655affb |
| 07-Jun-2013 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
ACPI / cpufreq: Add ACPI processor device IDs to acpi-cpufreq
After commit ac212b6 (ACPI / processor: Use common hotplug infrastructure) the acpi-cpufreq module is not loaded automatically by udev w
ACPI / cpufreq: Add ACPI processor device IDs to acpi-cpufreq
After commit ac212b6 (ACPI / processor: Use common hotplug infrastructure) the acpi-cpufreq module is not loaded automatically by udev which fails to match it against the x86cpu modalias. Still, it can be matched against ACPI processor device IDs, which even makes more sense, because it depends on the ACPI processor driver that uses those device IDs to bind to processor devices.
For this reason, add ACPI processor device IDs to acpi-cpufreq.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
show more ...
|
Revision tags: v3.10-rc4 |
|
#
8673b83b |
| 31-May-2013 |
Ross Lagerwall <rosslagerwall@gmail.com> |
acpi-cpufreq: set current frequency based on target P-State
Commit 4b31e774 (Always set P-state on initialization) fixed bug #4634 and caused the driver to always set the target P-State at least onc
acpi-cpufreq: set current frequency based on target P-State
Commit 4b31e774 (Always set P-state on initialization) fixed bug #4634 and caused the driver to always set the target P-State at least once since the initial P-State may not be the desired one. Commit 5a1c0228 (cpufreq: Avoid calling cpufreq driver's target() routine if target_freq == policy->cur) caused a regression in this behavior.
This fixes the regression by setting policy->cur based on the CPU's target frequency rather than the CPU's current reported frequency (which may be different). This means that the P-State will be set initially if the CPU's target frequency is different from the governor's target frequency.
This fixes an issue where setting the default governor to performance wouldn't correctly enable turbo mode on all cores.
Signed-off-by: Ross Lagerwall <rosslagerwall@gmail.com> Reviewed-by: Len Brown <len.brown@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: 3.8+ <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v3.10-rc3, v3.10-rc2, v3.10-rc1, v3.9, v3.9-rc8, v3.9-rc7, v3.9-rc6, v3.9-rc5 |
|
#
50701588 |
| 30-Mar-2013 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: rename index as driver_data in cpufreq_frequency_table
The "index" field of struct cpufreq_frequency_table was never an index and isn't used at all by the cpufreq core. It only is useful f
cpufreq: rename index as driver_data in cpufreq_frequency_table
The "index" field of struct cpufreq_frequency_table was never an index and isn't used at all by the cpufreq core. It only is useful for cpufreq drivers for their internal purposes.
Many people nowadays blindly set it in ascending order with the assumption that the core will use it, which is a mistake.
Rename it to "driver_data" as that's what its purpose is. All of its users are updated accordingly.
[rjw: Changelog] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
2361be23 |
| 17-May-2013 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: Don't create empty /sys/devices/system/cpu/cpufreq directory
When we don't have any file in cpu/cpufreq directory we shouldn't create it. Specially with the introduction of per-policy gover
cpufreq: Don't create empty /sys/devices/system/cpu/cpufreq directory
When we don't have any file in cpu/cpufreq directory we shouldn't create it. Specially with the introduction of per-policy governor instance patchset, even governors are moved to cpu/cpu*/cpufreq/governor-name directory and so this directory is just not required.
Lets have it only when required.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
b43a7ffb |
| 24-Mar-2013 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: Notify all policy->cpus in cpufreq_notify_transition()
policy->cpus contains all online cpus that have single shared clock line. And their frequencies are always updated together.
Many SMP
cpufreq: Notify all policy->cpus in cpufreq_notify_transition()
policy->cpus contains all online cpus that have single shared clock line. And their frequencies are always updated together.
Many SMP system's cpufreq drivers take care of this in individual drivers but the best place for this code is in cpufreq core.
This patch modifies cpufreq_notify_transition() to notify frequency change for all cpus in policy->cpus and hence updates all users of this API.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
aa77a527 |
| 24-Mar-2013 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: acpi-cpufreq: Don't set policy->related_cpus from .init()
With the addition of following patch:
fcf8058 cpufreq: Simplify cpufreq_add_dev()
cpufreq driver's .init() routine must initializ
cpufreq: acpi-cpufreq: Don't set policy->related_cpus from .init()
With the addition of following patch:
fcf8058 cpufreq: Simplify cpufreq_add_dev()
cpufreq driver's .init() routine must initialize policy->cpus with mask of all possible CPUs (Online + Offline) that share the clock. Then the core would copy this mask onto policy->related_cpus and will reset policy->cpus to carry only online cpus.
acpi-cpufreq driver wasn't updated with this assumption and so sometimes when we try to hot[un]plug CPUs at run time, sysfs directories get corrupted.
This patch fixes acpi-cpufreq driver against this corruption.
Reported-and-tested-by: Maciej Rutecki <maciej.rutecki@gmail.com> Tested-by: Borislav Petkov <bp@suse.de> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v3.9-rc4, v3.9-rc3, v3.9-rc2, v3.9-rc1, v3.8, v3.8-rc7, v3.8-rc6 |
|
#
2624f90c |
| 31-Jan-2013 |
Fabio Baltieri <fabio.baltieri@linaro.org> |
cpufreq: governors: implement generic policy_is_shared
Implement a generic helper function policy_is_shared() to replace the current dbs_sw_coordinated_cpus() at cpufreq level, so that it can be use
cpufreq: governors: implement generic policy_is_shared
Implement a generic helper function policy_is_shared() to replace the current dbs_sw_coordinated_cpus() at cpufreq level, so that it can be used by code other than cpufreq governors.
Suggested-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Fabio Baltieri <fabio.baltieri@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v3.8-rc5 |
|
#
c40a4518 |
| 20-Jan-2013 |
Matthew Garrett <mjg59@srcf.ucam.org> |
acpi-cpufreq: Do not load on K8
de3ed81d746d ("[CPUFREQ] Change link order of x86 cpufreq modules") changed cpufreq drivers link order so that powernow-k8 gets loaded first due to earlier K8s having
acpi-cpufreq: Do not load on K8
de3ed81d746d ("[CPUFREQ] Change link order of x86 cpufreq modules") changed cpufreq drivers link order so that powernow-k8 gets loaded first due to earlier K8s having BIOS bugs.
However, now that acpi-cpufreq supports both AMD and Intel CPUs with HW P-states, we want to load it first, so that cases where acpi-cpufreq and powernow-k8 are both built-in and powernow-k8 initializing first, can be addressed.
So, make sure that even if acpi-cpufreq gets loaded first, it errors out on K8s and powernow-k8 can be loaded then successfully.
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org> References: http://lkml.kernel.org/r/20130118162347.GA31499@srcf.ucam.org Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
efa17194 |
| 22-Jan-2013 |
Matthew Garrett <matthew.garrett@nebula.com> |
cpufreq: Add module aliases for acpi-cpufreq
The acpi core will call request_module("acpi-cpufreq") on subsystem init, but this will fail if the module isn't available at that stage of boot. Add som
cpufreq: Add module aliases for acpi-cpufreq
The acpi core will call request_module("acpi-cpufreq") on subsystem init, but this will fail if the module isn't available at that stage of boot. Add some module aliases to ensure that udev can load the module on Intel and AMD systems with the appropriate feature bits - I /think/ that this will also work on VIA systems, but haven't verified that.
References: http://lkml.kernel.org/r/1448223.sdUJnNSRz4@vostro.rjw.lan Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com> Tested-by: Leonid Isaev <lisaev@umail.iu.edu> Acked-by: Borislav Petkov <bp@suse.de> Cc: 3.7+ <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v3.8-rc4, v3.8-rc3, v3.8-rc2, v3.8-rc1, v3.7, v3.7-rc8, v3.7-rc7, v3.7-rc6, v3.7-rc5, v3.7-rc4, v3.7-rc3, v3.7-rc2, v3.7-rc1, v3.6, v3.6-rc7, v3.6-rc6, v3.6-rc5 |
|
#
11269ff5 |
| 04-Sep-2012 |
Andre Przywara <andre.przywara@amd.com> |
acpi-cpufreq: Add compatibility for legacy AMD cpb sysfs knob
The powernow-k8 driver supported a sysfs knob called "cpb", which was instantiated per CPU, but actually acted globally for the whole sy
acpi-cpufreq: Add compatibility for legacy AMD cpb sysfs knob
The powernow-k8 driver supported a sysfs knob called "cpb", which was instantiated per CPU, but actually acted globally for the whole system. To keep some compatibility with this feature, we re-introduce this behavior here, but: a) only enable it on AMD CPUs and b) protect it with a Kconfig switch
I'd like to consider this feature obsolete. Lets keep it around for some kernel versions and then phase it out.
Signed-off-by: Andre Przywara <andre.przywara@amd.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
show more ...
|
#
615b7300 |
| 04-Sep-2012 |
Andre Przywara <andre.przywara@amd.com> |
acpi-cpufreq: Add support for disabling dynamic overclocking
One feature present in powernow-k8 that isn't present in acpi-cpufreq is support for enabling or disabling AMD's core performance boost t
acpi-cpufreq: Add support for disabling dynamic overclocking
One feature present in powernow-k8 that isn't present in acpi-cpufreq is support for enabling or disabling AMD's core performance boost technology. This patch adds support to acpi-cpufreq, but also includes support for Intel's dynamic acceleration.
The original boost disabling sysfs file was per CPU, but acted globally. Also the naming (cpb) was at least not intuitive. So lets introduce a single file simply called "boost", which sits once in /sys/devices/system/cpu/cpufreq. This should be the only way of using this feature, so add documentation about the rationale and the usage.
A following patch will re-introduce the cpb knob for compatibility reasons on AMD CPUs.
Per-CPU boost switching is possible, but not trivial and is thus postponed to a later patch series.
Signed-off-by: Andre Przywara <andre.przywara@amd.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
show more ...
|
#
acd31624 |
| 04-Sep-2012 |
Andre Przywara <andre.przywara@amd.com> |
acpi-cpufreq: Add quirk to disable _PSD usage on all AMD CPUs
To workaround some Windows specific behavior, the ACPI _PSD table on AMD desktop boards advertises all cores as dependent, meaning that
acpi-cpufreq: Add quirk to disable _PSD usage on all AMD CPUs
To workaround some Windows specific behavior, the ACPI _PSD table on AMD desktop boards advertises all cores as dependent, meaning that they all can only use the same P-state. acpi-cpufreq strictly obeys this description, instantiating one CPU only and symlinking the others. But the hardware can have distinct frequencies for each core and powernow-k8 did it that way. So, in order to use the hardware to its full potential and keep the original powernow-k8 behavior, lets override the _PSD table setting on AMD hardware. We use the siblings table, as it matches the current hardware behavior.
Signed-off-by: Andre Przywara <andre.przywara@amd.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
show more ...
|
#
3dc9a633 |
| 04-Sep-2012 |
Matthew Garrett <mjg@redhat.com> |
acpi-cpufreq: Add support for modern AMD CPUs
The programming model for P-states on modern AMD CPUs is very similar to that of Intel and VIA. It makes sense to consolidate this support into one driv
acpi-cpufreq: Add support for modern AMD CPUs
The programming model for P-states on modern AMD CPUs is very similar to that of Intel and VIA. It makes sense to consolidate this support into one driver rather than duplicating functionality between two of them. This patch adds support for AMDs with hardware P-state control to acpi-cpufreq.
Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Andre Przywara <andre.przywara@amd.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
show more ...
|
Revision tags: v3.6-rc4, v3.6-rc3, v3.6-rc2, v3.6-rc1, v3.5, v3.5-rc7, v3.5-rc6, v3.5-rc5, v3.5-rc4, v3.5-rc3, v3.5-rc2, v3.5-rc1, v3.4, v3.4-rc7, v3.4-rc6, v3.4-rc5, v3.4-rc4, v3.4-rc3, v3.4-rc2, v3.4-rc1, v3.3, v3.3-rc7, v3.3-rc6, v3.3-rc5, v3.3-rc4, v3.3-rc3, v3.3-rc2, v3.3-rc1, v3.2, v3.2-rc7, v3.2-rc6, v3.2-rc5, v3.2-rc4, v3.2-rc3, v3.2-rc2, v3.2-rc1, v3.1, v3.1-rc10, v3.1-rc9, v3.1-rc8, v3.1-rc7, v3.1-rc6, v3.1-rc5, v3.1-rc4, v3.1-rc3, v3.1-rc2, v3.1-rc1, v3.0 |
|
#
92e03c41 |
| 13-Jul-2011 |
Matthew Garrett <mjg@redhat.com> |
[CPUFREQ] Handle CPUs with different capabilities in acpi-cpufreq
acpi-cpufreq checks each CPU for aperf/mperf support, but only sets a global flag. This will cause errors if some CPUs in the system
[CPUFREQ] Handle CPUs with different capabilities in acpi-cpufreq
acpi-cpufreq checks each CPU for aperf/mperf support, but only sets a global flag. This will cause errors if some CPUs in the system don't support the feature. Check boot_cpu_has() instead in order to make sure that all CPUs support it.
Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Dave Jones <davej@redhat.com>
show more ...
|
Revision tags: v3.0-rc7 |
|
#
50f4ddd4 |
| 08-Jul-2011 |
Luming Yu <luming.yu@gmail.com> |
[CPUFREQ] fix cpumask memory leak in acpi-cpufreq on cpu hotplug.
I came across a memory leak during a cyclic cpu-online-offline test.
Signed-off-by: Yu Luming <luming.yu@intel.com> Cc: Len Brown <
[CPUFREQ] fix cpumask memory leak in acpi-cpufreq on cpu hotplug.
I came across a memory leak during a cyclic cpu-online-offline test.
Signed-off-by: Yu Luming <luming.yu@intel.com> Cc: Len Brown <lenb@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dave Jones <davej@redhat.com>
show more ...
|
Revision tags: v3.0-rc6, v3.0-rc5, v3.0-rc4, v3.0-rc3, v3.0-rc2, v3.0-rc1 |
|
#
bb0a56ec |
| 19-May-2011 |
Dave Jones <davej@redhat.com> |
[CPUFREQ] Move x86 drivers to drivers/cpufreq/
Signed-off-by: Dave Jones <davej@redhat.com>
|
#
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 ta
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
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 wh
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 (Fa
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/cpufr
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 i
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. Determ
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 ...
|