* Re: [PATCH] ACPI: processor idle: Practically limit "Dummy wait" workaround to old Intel systems [not found] <20220922184745.3252932-1-dave.hansen@intel.com> @ 2022-09-22 18:53 ` Rafael J. Wysocki 2022-09-22 18:57 ` Limonciello, Mario 2022-09-22 19:01 ` Dave Hansen 0 siblings, 2 replies; 5+ messages in thread From: Rafael J. Wysocki @ 2022-09-22 18:53 UTC (permalink / raw) To: Dave Hansen, linux-kernel Cc: Dave Hansen, Len Brown, Mario Limonciello, Peter Zijlstra, Borislav Petkov, K Prateek Nayak, linux-acpi, Linux PM On 9/22/2022 8:47 PM, Dave Hansen wrote: > 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. > > Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> > Cc: Len Brown <lenb@kernel.org> > Cc: Mario Limonciello <Mario.Limonciello@amd.com> > Cc: Peter Zijlstra (Intel) <peterz@infradead.org> > Cc: Borislav Petkov <bp@alien8.de> > Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > Reported-by: K Prateek Nayak <kprateek.nayak@amd.com> > Link: https://lore.kernel.org/all/20220921063638.2489-1-kprateek.nayak@amd.com/ Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> or do you want me to pick this up? > --- > 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 16a1663d02d4..9f40917c49ef 100644 > --- 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); > } > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] ACPI: processor idle: Practically limit "Dummy wait" workaround to old Intel systems 2022-09-22 18:53 ` [PATCH] ACPI: processor idle: Practically limit "Dummy wait" workaround to old Intel systems Rafael J. Wysocki @ 2022-09-22 18:57 ` Limonciello, Mario 2022-09-22 19:01 ` Dave Hansen 1 sibling, 0 replies; 5+ messages in thread From: Limonciello, Mario @ 2022-09-22 18:57 UTC (permalink / raw) To: Rafael J. Wysocki, Dave Hansen, linux-kernel Cc: Dave Hansen, Len Brown, Peter Zijlstra, Borislav Petkov, K Prateek Nayak, linux-acpi, Linux PM On 9/22/2022 13:53, Rafael J. Wysocki wrote: > On 9/22/2022 8:47 PM, Dave Hansen wrote: >> 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. >> >> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> >> Cc: Len Brown <lenb@kernel.org> >> Cc: Mario Limonciello <Mario.Limonciello@amd.com> >> Cc: Peter Zijlstra (Intel) <peterz@infradead.org> >> Cc: Borislav Petkov <bp@alien8.de> >> Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> >> Reported-by: K Prateek Nayak <kprateek.nayak@amd.com> >> Link: >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2F20220921063638.2489-1-kprateek.nayak%40amd.com%2F&data=05%7C01%7CMario.Limonciello%40amd.com%7C8460d9ef3add45bf571408da9ccbc58a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637994696248641733%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=23k2wKPZaBrgOTtcHw8ByNzfsus1RSsdXMlCACjl%2Bmc%3D&reserved=0 If agreeable, I think this should be @stable too. Either way: Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> >> > > Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > or do you want me to pick this up? > > >> --- >> 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 16a1663d02d4..9f40917c49ef 100644 >> --- 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); >> } > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] ACPI: processor idle: Practically limit "Dummy wait" workaround to old Intel systems 2022-09-22 18:53 ` [PATCH] ACPI: processor idle: Practically limit "Dummy wait" workaround to old Intel systems Rafael J. Wysocki 2022-09-22 18:57 ` Limonciello, Mario @ 2022-09-22 19:01 ` Dave Hansen 2022-09-23 18:36 ` Kim Phillips 1 sibling, 1 reply; 5+ messages in thread From: Dave Hansen @ 2022-09-22 19:01 UTC (permalink / raw) To: Rafael J. Wysocki, linux-kernel Cc: Dave Hansen, Len Brown, Mario Limonciello, Peter Zijlstra, Borislav Petkov, K Prateek Nayak, linux-acpi, Linux PM On 9/22/22 11:53, Rafael J. Wysocki wrote: > Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > or do you want me to pick this up? I'll just stick it in x86/urgent. It's modifying code in a x86 #ifdef. I'll call it a small enclave of sovereign x86 territory in ACPI land, just like an embassy. ;) ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] ACPI: processor idle: Practically limit "Dummy wait" workaround to old Intel systems 2022-09-22 19:01 ` Dave Hansen @ 2022-09-23 18:36 ` Kim Phillips 2022-09-26 21:49 ` Dave Hansen 0 siblings, 1 reply; 5+ messages in thread From: Kim Phillips @ 2022-09-23 18:36 UTC (permalink / raw) To: Dave Hansen, Rafael J. Wysocki, linux-kernel Cc: Dave Hansen, Len Brown, Mario Limonciello, Peter Zijlstra, Borislav Petkov, K Prateek Nayak, linux-acpi, Linux PM, stable On 9/22/22 2:01 PM, Dave Hansen wrote: > On 9/22/22 11:53, Rafael J. Wysocki wrote: >> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> >> >> or do you want me to pick this up? > > I'll just stick it in x86/urgent. > > It's modifying code in a x86 #ifdef. I'll call it a small enclave of > sovereign x86 territory in ACPI land, just like an embassy. ;) Can it be cc:stable@vger.kernel.org, since it applies cleanly as far back as this v5.4 commit?: commit fa583f71a99c85e52781ed877c82c8757437b680 Author: Yin Fengwei <fengwei.yin@intel.com> Date: Thu Oct 24 15:04:20 2019 +0800 ACPI: processor_idle: Skip dummy wait if kernel is in guest Thanks, Kim ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] ACPI: processor idle: Practically limit "Dummy wait" workaround to old Intel systems 2022-09-23 18:36 ` Kim Phillips @ 2022-09-26 21:49 ` Dave Hansen 0 siblings, 0 replies; 5+ messages in thread From: Dave Hansen @ 2022-09-26 21:49 UTC (permalink / raw) To: Kim Phillips, Rafael J. Wysocki, linux-kernel Cc: Dave Hansen, Len Brown, Mario Limonciello, Peter Zijlstra, Borislav Petkov, K Prateek Nayak, linux-acpi, Linux PM, stable On 9/23/22 11:36, Kim Phillips wrote: > Can it be cc:stable@vger.kernel.org, since it applies cleanly as far > back as this v5.4 commit?: I just sent the pull request to Linus for this fix. I realized that I didn't tag it for stable@. If it gets applied, I'll send a request for it to be picked up for stable@, via "Option 2": > Option 2 > ******** > > After the patch has been merged to Linus' tree, send an email to > stable@vger.kernel.org containing the subject of the patch, the commit ID, > why you think it should be applied, and what kernel version you wish it to > be applied to. Sorry about that. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-09-26 21:49 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20220922184745.3252932-1-dave.hansen@intel.com> 2022-09-22 18:53 ` [PATCH] ACPI: processor idle: Practically limit "Dummy wait" workaround to old Intel systems Rafael J. Wysocki 2022-09-22 18:57 ` Limonciello, Mario 2022-09-22 19:01 ` Dave Hansen 2022-09-23 18:36 ` Kim Phillips 2022-09-26 21:49 ` Dave Hansen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).