From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
patches@lists.linux.dev, K Prateek Nayak <kprateek.nayak@amd.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Mario Limonciello <mario.limonciello@amd.com>,
"Guilherme G. Piccoli" <gpiccoli@igalia.com>
Subject: [PATCH 5.15 14/20] ACPI: processor idle: Practically limit "Dummy wait" workaround to old Intel systems
Date: Fri, 3 Feb 2023 11:13:41 +0100 [thread overview]
Message-ID: <20230203101008.597318076@linuxfoundation.org> (raw)
In-Reply-To: <20230203101007.985835823@linuxfoundation.org>
From: Dave Hansen <dave.hansen@intel.com>
commit e400ad8b7e6a1b9102123c6240289a811501f7d9 upstream.
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
Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/acpi/processor_idle.c | 23 ++++++++++++++++++++---
1 file changed, 20 insertions(+), 3 deletions(-)
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -531,10 +531,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);
}
next prev parent reply other threads:[~2023-02-03 10:24 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-03 10:13 [PATCH 5.15 00/20] 5.15.92-rc1 review Greg Kroah-Hartman
2023-02-03 10:13 ` [PATCH 5.15 01/20] ARM: dts: imx: Fix pca9547 i2c-mux node name Greg Kroah-Hartman
2023-02-03 10:13 ` [PATCH 5.15 02/20] ARM: dts: vf610: Fix pca9548 i2c-mux node names Greg Kroah-Hartman
2023-02-03 10:13 ` [PATCH 5.15 03/20] arm64: dts: freescale: Fix pca954x " Greg Kroah-Hartman
2023-02-03 10:13 ` [PATCH 5.15 04/20] arm64: dts: imx8mq-thor96: fix no-mmc property for SDHCI Greg Kroah-Hartman
2023-02-03 10:13 ` [PATCH 5.15 05/20] firmware: arm_scmi: Clear stale xfer->hdr.status Greg Kroah-Hartman
2023-02-03 10:13 ` [PATCH 5.15 06/20] bpf: Skip task with pid=1 in send_signal_common() Greg Kroah-Hartman
2023-02-03 10:13 ` [PATCH 5.15 07/20] erofs/zmap.c: Fix incorrect offset calculation Greg Kroah-Hartman
2023-02-03 10:13 ` [PATCH 5.15 08/20] blk-cgroup: fix missing pd_online_fn() while activating policy Greg Kroah-Hartman
2023-02-03 10:13 ` [PATCH 5.15 09/20] HID: playstation: sanity check DualSense calibration data Greg Kroah-Hartman
2023-02-03 10:13 ` [PATCH 5.15 10/20] dmaengine: imx-sdma: Fix a possible memory leak in sdma_transfer_init Greg Kroah-Hartman
2023-02-03 10:13 ` [PATCH 5.15 11/20] cifs: fix return of uninitialized rc in dfs_cache_update_tgthint() Greg Kroah-Hartman
2023-02-03 10:13 ` [PATCH 5.15 12/20] ext4: fix bad checksum after online resize Greg Kroah-Hartman
2023-02-03 10:13 ` [PATCH 5.15 13/20] extcon: usbc-tusb320: fix kernel-doc warning Greg Kroah-Hartman
2023-02-03 10:13 ` Greg Kroah-Hartman [this message]
2023-02-03 10:13 ` [PATCH 5.15 15/20] Bluetooth: fix null ptr deref on hci_sync_conn_complete_evt Greg Kroah-Hartman
2023-02-03 10:13 ` [PATCH 5.15 16/20] tools: fix ARRAY_SIZE defines in tools and selftests hdrs Greg Kroah-Hartman
2023-02-03 10:13 ` [PATCH 5.15 17/20] selftests/vm: remove ARRAY_SIZE define from individual tests Greg Kroah-Hartman
2023-02-03 10:13 ` [PATCH 5.15 18/20] selftests: Provide local define of __cpuid_count() Greg Kroah-Hartman
2023-02-03 10:13 ` [PATCH 5.15 19/20] net: fix NULL pointer in skb_segment_list Greg Kroah-Hartman
2023-02-03 10:13 ` [PATCH 5.15 20/20] net: mctp: purge receive queues on sk destruction Greg Kroah-Hartman
2023-02-03 20:03 ` [PATCH 5.15 00/20] 5.15.92-rc1 review Florian Fainelli
2023-02-04 0:53 ` Shuah Khan
2023-02-04 1:50 ` Guenter Roeck
2023-02-04 2:03 ` Bagas Sanjaya
2023-02-04 8:31 ` Naresh Kamboju
2023-02-04 8:55 ` Ron Economos
2023-02-06 7:12 ` Greg Kroah-Hartman
2023-02-06 8:56 ` Jon Hunter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230203101008.597318076@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--cc=dave.hansen@linux.intel.com \
--cc=gpiccoli@igalia.com \
--cc=kprateek.nayak@amd.com \
--cc=mario.limonciello@amd.com \
--cc=patches@lists.linux.dev \
--cc=rafael.j.wysocki@intel.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox