/[packages]/backports/8/kernel/current/SOURCES/ACPI-processor-idle-Practically-limit-Dummy-wait-wor.patch
ViewVC logotype

Annotation of /backports/8/kernel/current/SOURCES/ACPI-processor-idle-Practically-limit-Dummy-wait-wor.patch

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1892788 - (hide annotations) (download)
Tue Sep 27 13:15:20 2022 UTC (18 months ago) by tmb
File size: 3166 byte(s)
- ACPI: processor idle: Practically limit "Dummy wait"  workaround to
  old Intel systems


1 tmb 1892788 From e400ad8b7e6a1b9102123c6240289a811501f7d9 Mon Sep 17 00:00:00 2001
2     From: Dave Hansen <dave.hansen@intel.com>
3     Date: Thu, 22 Sep 2022 11:47:45 -0700
4     Subject: [PATCH] ACPI: processor idle: Practically limit "Dummy wait"
5     workaround to old Intel systems
6    
7     Old, circa 2002 chipsets have a bug: they don't go idle when they are
8     supposed to. So, a workaround was added to slow the CPU down and
9     ensure that the CPU waits a bit for the chipset to actually go idle.
10     This workaround is ancient and has been in place in some form since
11     the original kernel ACPI implementation.
12    
13     But, this workaround is very painful on modern systems. The "inl()"
14     can take thousands of cycles (see Link: for some more detailed
15     numbers and some fun kernel archaeology).
16    
17     First and foremost, modern systems should not be using this code.
18     Typical Intel systems have not used it in over a decade because it is
19     horribly inferior to MWAIT-based idle.
20    
21     Despite this, people do seem to be tripping over this workaround on
22     AMD system today.
23    
24     Limit the "dummy wait" workaround to Intel systems. Keep Modern AMD
25     systems from tripping over the workaround. Remotely modern Intel
26     systems use intel_idle instead of this code and will, in practice,
27     remain unaffected by the dummy wait.
28    
29     Reported-by: K Prateek Nayak <kprateek.nayak@amd.com>
30     Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
31     Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
32     Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
33     Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
34     Link: https://lore.kernel.org/all/20220921063638.2489-1-kprateek.nayak@amd.com/
35     Link: https://lkml.kernel.org/r/20220922184745.3252932-1-dave.hansen@intel.com
36     ---
37     drivers/acpi/processor_idle.c | 23 ++++++++++++++++++++---
38     1 file changed, 20 insertions(+), 3 deletions(-)
39    
40     diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
41     index 16a1663d02d4..9f40917c49ef 100644
42     --- a/drivers/acpi/processor_idle.c
43     +++ b/drivers/acpi/processor_idle.c
44     @@ -531,10 +531,27 @@ static void wait_for_freeze(void)
45     /* No delay is needed if we are in guest */
46     if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
47     return;
48     + /*
49     + * Modern (>=Nehalem) Intel systems use ACPI via intel_idle,
50     + * not this code. Assume that any Intel systems using this
51     + * are ancient and may need the dummy wait. This also assumes
52     + * that the motivating chipset issue was Intel-only.
53     + */
54     + if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
55     + return;
56     #endif
57     - /* Dummy wait op - must do something useless after P_LVL2 read
58     - because chipsets cannot guarantee that STPCLK# signal
59     - gets asserted in time to freeze execution properly. */
60     + /*
61     + * Dummy wait op - must do something useless after P_LVL2 read
62     + * because chipsets cannot guarantee that STPCLK# signal gets
63     + * asserted in time to freeze execution properly
64     + *
65     + * This workaround has been in place since the original ACPI
66     + * implementation was merged, circa 2002.
67     + *
68     + * If a profile is pointing to this instruction, please first
69     + * consider moving your system to a more modern idle
70     + * mechanism.
71     + */
72     inl(acpi_gbl_FADT.xpm_timer_block.address);
73     }
74    
75     --
76     2.37.3
77    

  ViewVC Help
Powered by ViewVC 1.1.30