Messages in this thread | | | From | "Limonciello, Mario" <> | Subject | RE: [PATCH] ACPI: processor_idle: Skip dummy wait for processors based on the Zen microarchitecture | Date | Thu, 22 Sep 2022 21:38:11 +0000 |
| |
[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.
| |