* 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).