lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 22 Sep 2022 21:42:15 +0200 From: Andreas Mohr <andi@...as.de> To: Dave Hansen <dave.hansen@...el.com> Cc: K Prateek Nayak <kprateek.nayak@....com>, linux-kernel@...r.kernel.org, rafael@...nel.org, lenb@...nel.org, linux-acpi@...r.kernel.org, linux-pm@...r.kernel.org, dave.hansen@...ux.intel.com, bp@...en8.de, tglx@...utronix.de, andi@...as.de, puwen@...on.cn, mario.limonciello@....com, peterz@...radead.org, rui.zhang@...el.com, gpiccoli@...lia.com, daniel.lezcano@...aro.org, ananth.narayan@....com, gautham.shenoy@....com, Calvin Ong <calvin.ong@....com>, stable@...r.kernel.org, regressions@...ts.linux.dev Subject: Re: [PATCH] ACPI: processor_idle: Skip dummy wait for processors based on the Zen microarchitecture 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# signal > - gets 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
Powered by blists - more mailing lists