Re: [PATCH 2/8 v2] acpi-cpufreq: Add quirk to disable _PSD usage on all AMD CPUs
On Monday, September 17, 2012 09:41:20 AM Andre Przywara wrote: > On 09/15/2012 01:20 PM, Konrad Rzeszutek Wilk wrote: > > ... > This was to overcome some nasty interaction between the Windows > scheduler and their version of the ondemand governor. Whoever is/was responsible for this, can you explain him/her that this was a bad idea and why. Is this part of a BKDG? Can you point to a public spec and the exact wording of the "Windows scheduler workaround" BIOS vendors shall do? > + pr_info_once(PFX "overriding BIOS provided _PSD data\n"); The message shows up on nearly every platform wether a _PSD function exists or not. This is wrong. If it's _PSD info that should get ignored/overwritten, this should be done where _PSD is obtained: processor_perflib.c Are you sure that it will never make sense for AMD to make use of _PSD tables? If yes, then always ignoring might be an option. If not, this might need a more specific check, e.g.: - Latest Windows version support called via OSI interface? Latest Windowses should/may not need this anymore? - Check for Desktop CPUs that are affected by the bad spec? Hm, as powernow-k8 never made use of _PSD, ignoring it for now sounds like a good thing to do. Still the ignoring should get moved to processor_perflib.c, best with a pointer or at least a comment that _PSD can be dangerous on AMD platforms. At some day _PSD may make sense for AMD platforms as well? Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8 v2] acpi-cpufreq: Add quirk to disable _PSD usage on all AMD CPUs
On 09/15/2012 01:20 PM, Konrad Rzeszutek Wilk wrote: On Sep 4, 2012 4:26 AM, "Andre Przywara" mailto:andre.przyw...@amd.com>> wrote: > > 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. Can you tell on which motherboards this different freq on cores can be exposed? Actually I think the motherboard is not the limiting factor here. Per-core P-states are possible on AMD Family 10h and greater CPUs, so Phenoms/Barcelona and beyond. You may need an AM2+/AM3 board, though. Fam10h CPUs run in some older AM2-only boards, but the power-management capabilities may be limited here. This definitely applies to the voltage (single power plane only), but the older BIOS on these boards may limit the frequency switching also. The actual reason for this patch is the (Fam10h) BKDG [1] recommendation in chapter 2.4.2.13.4 _PSD (P-State Dependency). There advertising only one possible P-state per package is recommended - for desktop CPUs (which are supposed to run Windows ;-) This was to overcome some nasty interaction between the Windows scheduler and their version of the ondemand governor. Regards, Andre. [1] http://support.amd.com/us/Processor_TechDocs/31116.pdf -- Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8 v2] acpi-cpufreq: Add quirk to disable _PSD usage on all AMD CPUs
On 09/15/2012 01:20 PM, Konrad Rzeszutek Wilk wrote: On Sep 4, 2012 4:26 AM, Andre Przywara andre.przyw...@amd.com mailto:andre.przyw...@amd.com wrote: 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. Can you tell on which motherboards this different freq on cores can be exposed? Actually I think the motherboard is not the limiting factor here. Per-core P-states are possible on AMD Family 10h and greater CPUs, so Phenoms/Barcelona and beyond. You may need an AM2+/AM3 board, though. Fam10h CPUs run in some older AM2-only boards, but the power-management capabilities may be limited here. This definitely applies to the voltage (single power plane only), but the older BIOS on these boards may limit the frequency switching also. The actual reason for this patch is the (Fam10h) BKDG [1] recommendation in chapter 2.4.2.13.4 _PSD (P-State Dependency). There advertising only one possible P-state per package is recommended - for desktop CPUs (which are supposed to run Windows ;-) This was to overcome some nasty interaction between the Windows scheduler and their version of the ondemand governor. Regards, Andre. [1] http://support.amd.com/us/Processor_TechDocs/31116.pdf -- Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8 v2] acpi-cpufreq: Add quirk to disable _PSD usage on all AMD CPUs
On Monday, September 17, 2012 09:41:20 AM Andre Przywara wrote: On 09/15/2012 01:20 PM, Konrad Rzeszutek Wilk wrote: ... This was to overcome some nasty interaction between the Windows scheduler and their version of the ondemand governor. Whoever is/was responsible for this, can you explain him/her that this was a bad idea and why. Is this part of a BKDG? Can you point to a public spec and the exact wording of the Windows scheduler workaround BIOS vendors shall do? + pr_info_once(PFX overriding BIOS provided _PSD data\n); The message shows up on nearly every platform wether a _PSD function exists or not. This is wrong. If it's _PSD info that should get ignored/overwritten, this should be done where _PSD is obtained: processor_perflib.c Are you sure that it will never make sense for AMD to make use of _PSD tables? If yes, then always ignoring might be an option. If not, this might need a more specific check, e.g.: - Latest Windows version support called via OSI interface? Latest Windowses should/may not need this anymore? - Check for Desktop CPUs that are affected by the bad spec? Hm, as powernow-k8 never made use of _PSD, ignoring it for now sounds like a good thing to do. Still the ignoring should get moved to processor_perflib.c, best with a pointer or at least a comment that _PSD can be dangerous on AMD platforms. At some day _PSD may make sense for AMD platforms as well? Thomas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/8 v2] 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
---
drivers/cpufreq/acpi-cpufreq.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 067a61f..70e7173 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -51,6 +51,8 @@ MODULE_AUTHOR("Paul Diefenbaugh, Dominik Brodowski");
MODULE_DESCRIPTION("ACPI Processor P-States Driver");
MODULE_LICENSE("GPL");
+#define PFX "acpi-cpufreq: "
+
enum {
UNDEFINED_CAPABLE = 0,
SYSTEM_INTEL_MSR_CAPABLE,
@@ -586,6 +588,14 @@ static int acpi_cpufreq_cpu_init(struct cpufreq_policy
*policy)
policy->shared_type = CPUFREQ_SHARED_TYPE_ALL;
cpumask_copy(policy->cpus, cpu_core_mask(cpu));
}
+
+ if (check_amd_hwpstate_cpu(cpu) && !acpi_pstate_strict) {
+ cpumask_clear(policy->cpus);
+ cpumask_set_cpu(cpu, policy->cpus);
+ cpumask_copy(policy->related_cpus, cpu_sibling_mask(cpu));
+ policy->shared_type = CPUFREQ_SHARED_TYPE_HW;
+ pr_info_once(PFX "overriding BIOS provided _PSD data\n");
+ }
#endif
/* capability check */
--
1.7.12
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/8 v2] 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.przyw...@amd.com
---
drivers/cpufreq/acpi-cpufreq.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 067a61f..70e7173 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -51,6 +51,8 @@ MODULE_AUTHOR(Paul Diefenbaugh, Dominik Brodowski);
MODULE_DESCRIPTION(ACPI Processor P-States Driver);
MODULE_LICENSE(GPL);
+#define PFX acpi-cpufreq:
+
enum {
UNDEFINED_CAPABLE = 0,
SYSTEM_INTEL_MSR_CAPABLE,
@@ -586,6 +588,14 @@ static int acpi_cpufreq_cpu_init(struct cpufreq_policy
*policy)
policy-shared_type = CPUFREQ_SHARED_TYPE_ALL;
cpumask_copy(policy-cpus, cpu_core_mask(cpu));
}
+
+ if (check_amd_hwpstate_cpu(cpu) !acpi_pstate_strict) {
+ cpumask_clear(policy-cpus);
+ cpumask_set_cpu(cpu, policy-cpus);
+ cpumask_copy(policy-related_cpus, cpu_sibling_mask(cpu));
+ policy-shared_type = CPUFREQ_SHARED_TYPE_HW;
+ pr_info_once(PFX overriding BIOS provided _PSD data\n);
+ }
#endif
/* capability check */
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
