diff options
Diffstat (limited to '0008-ACPI-processor-idle-Practically-limit-Dummy-wait-wor.patch')
| -rw-r--r-- | 0008-ACPI-processor-idle-Practically-limit-Dummy-wait-wor.patch | 77 |
1 files changed, 0 insertions, 77 deletions
diff --git a/0008-ACPI-processor-idle-Practically-limit-Dummy-wait-wor.patch b/0008-ACPI-processor-idle-Practically-limit-Dummy-wait-wor.patch deleted file mode 100644 index 2e5ecaf..0000000 --- a/0008-ACPI-processor-idle-Practically-limit-Dummy-wait-wor.patch +++ /dev/null @@ -1,77 +0,0 @@ -From 3003a9e309999c6417f2927fa3689ee8e45c9be2 Mon Sep 17 00:00:00 2001 -From: Dave Hansen <dave.hansen@intel.com> -Date: Thu, 22 Sep 2022 11:47:45 -0700 -Subject: [PATCH 8/9] ACPI: processor idle: Practically limit "Dummy wait" - workaround to old Intel systems - -Old, circa 2002 chipsets have a bug: they don't go idle when they are -supposed to. So, a workaround was added to slow the CPU down and -ensure that the CPU waits a bit for the chipset to actually go idle. -This workaround is ancient and has been in place in some form since -the original kernel ACPI implementation. - -But, this workaround is very painful on modern systems. The "inl()" -can take thousands of cycles (see Link: for some more detailed -numbers and some fun kernel archaeology). - -First and foremost, modern systems should not be using this code. -Typical Intel systems have not used it in over a decade because it is -horribly inferior to MWAIT-based idle. - -Despite this, people do seem to be tripping over this workaround on -AMD system today. - -Limit the "dummy wait" workaround to Intel systems. Keep Modern AMD -systems from tripping over the workaround. Remotely modern Intel -systems use intel_idle instead of this code and will, in practice, -remain unaffected by the dummy wait. - -Reported-by: K Prateek Nayak <kprateek.nayak@amd.com> -Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> -Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> -Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> -Tested-by: K Prateek Nayak <kprateek.nayak@amd.com> -Link: https://lore.kernel.org/all/20220921063638.2489-1-kprateek.nayak@amd.com/ -Link: https://lkml.kernel.org/r/20220922184745.3252932-1-dave.hansen@intel.com ---- - drivers/acpi/processor_idle.c | 23 ++++++++++++++++++++--- - 1 file changed, 20 insertions(+), 3 deletions(-) - -diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c -index 13200969ccf3..5168b6624b42 100644 ---- a/drivers/acpi/processor_idle.c -+++ b/drivers/acpi/processor_idle.c -@@ -530,10 +530,27 @@ static void wait_for_freeze(void) - /* No delay is needed if we are in guest */ - if (boot_cpu_has(X86_FEATURE_HYPERVISOR)) - return; -+ /* -+ * Modern (>=Nehalem) Intel systems use ACPI via intel_idle, -+ * not this code. Assume that any Intel systems using this -+ * are ancient and may need the dummy wait. This also assumes -+ * that the motivating chipset issue was Intel-only. -+ */ -+ if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) -+ return; - #endif -- /* Dummy wait op - must do something useless after P_LVL2 read -- because chipsets cannot guarantee that STPCLK# signal -- gets asserted in time to freeze execution properly. */ -+ /* -+ * Dummy wait op - must do something useless after P_LVL2 read -+ * because chipsets cannot guarantee that STPCLK# signal gets -+ * asserted in time to freeze execution properly -+ * -+ * This workaround has been in place since the original ACPI -+ * implementation was merged, circa 2002. -+ * -+ * If a profile is pointing to this instruction, please first -+ * consider moving your system to a more modern idle -+ * mechanism. -+ */ - inl(acpi_gbl_FADT.xpm_timer_block.address); - } - --- -2.37.2 - |