Hi,
On Thu, Sep 22, 2022 at 10:01:46AM -0700, Dave Hansen wrote:
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# signalgets asserted in time to freeze execution properly. */
16 years ago, I did my testing on a VIA 8233/8235 chipset (AMD Athlon/Duron) system...... (plus reading VIA spec PDFs which mentioned "STPCLK#" etc.).
AFAIR I was doing kernel profiling (via oprofile, IIRC) for painful performance hotspots (read: I/O accesses etc.), and this was one resulting place which I stumbled over. And if I'm not completely mistaken, that dummy wait I/O op *was* needed (else "nice" effects) on my system (put loud and clear: *non*-Intel).
So one can see where my profiling effort went (*optimizing* things, not degrading them) --> hints that current Zen3-originating effort is not about a regression in the "regression bug" sense - merely a (albeit rather appreciable/sizeable... congrats!) performance deterioration vs. an optimal (currently non-achieved) software implementation state (also: of PORT-based handling [vs. MWAIT], mind you!).
I still have that VIA hardware, but inactive (had the oh-so-usual capacitors issue :( ).
Sorry for sabotaging your current fix efforts ;-) - but thank you very much for your work/discussion in this very central/hotpath area! (this extends to all of you...)
Greetings
Andreas Mohr