RE: [PATCH] ACPI: processor_idle: Skip dummy wait for processors based on the Zen microarchitecture

["Limonciello, Mario" <Mario.Limonciello@amd.com>]

[Public]



> -----Original Message-----
> From: Dave Hansen <dave.hansen@intel.com>
> Sent: Thursday, September 22, 2022 16:22
> To: Andreas Mohr <andi@lisas.de>
> Cc: Nayak, K Prateek <KPrateek.Nayak@amd.com>; linux-
> kernel@vger.kernel.org; rafael@kernel.org; lenb@kernel.org; linux-
> acpi@vger.kernel.org; linux-pm@vger.kernel.org;
> dave.hansen@linux.intel.com; bp@alien8.de; tglx@linutronix.de;
> puwen@hygon.cn; Limonciello, Mario <Mario.Limonciello@amd.com>;
> peterz@infradead.org; rui.zhang@intel.com; gpiccoli@igalia.com;
> daniel.lezcano@linaro.org; Narayan, Ananth <Ananth.Narayan@amd.com>;
> Shenoy, Gautham Ranjal <gautham.shenoy@amd.com>; Ong, Calvin
> <Calvin.Ong@amd.com>; stable@vger.kernel.org;
> regressions@lists.linux.dev
> Subject: Re: [PATCH] ACPI: processor_idle: Skip dummy wait for processors
> based on the Zen microarchitecture
> 
> On 9/22/22 13:10, Andreas Mohr wrote:
> >   (- but then what about other more modern chipsets?)
> >
> > --> we need to achieve (hopefully sufficiently precisely) a solution which
> > takes into account Zen3 STPCLK# improvements while
> > preserving "accepted" behaviour/requirements on *all* STPCLK#-
> hampered chipsets
> > ("STPCLK# I/O wait is default/traditional handling"?).
> 
> Ideally, sure.  But, we're talking about theoretically regressing the
> idle behavior of some indeterminate set of old systems, the majority of
> which are sitting in a puddle of capacitor goo at the bottom of a
> landfill right now.  This is far from an ideal situation.
> 
> FWIW, I'd much rather do something like
> 
> 	if ((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) &&
> 	    (boot_cpu_data.x86_model >= 0xF))
> 		return;
> 
> 	inl(slow_whatever);
> 
> than a Zen check.  AMD has, as far as I know, been a lot more sequential
> and sane about model numbers than Intel, and there are some AMD model
> number range checks in the codebase today.
> 
> A check like this would also be _relatively_ future-proof in the case
> that X86_FEATURE_ZEN stops getting set on future AMD CPUs.  That's a lot
> more likely than AMD going and reusing a <0xF model.

If you're going to use a family check instead it should be 0x17 or newer.
(c->x86 >= 0x17)

That does match what's used to set X86_FEATURE_ZEN at least then right now too.