[Public] > -----Original Message----- > From: Dave Hansen <dave.hansen@xxxxxxxxx> > Sent: Thursday, September 22, 2022 13:18 > To: Limonciello, Mario <Mario.Limonciello@xxxxxxx>; Nayak, K Prateek > <KPrateek.Nayak@xxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx > Cc: rafael@xxxxxxxxxx; lenb@xxxxxxxxxx; linux-acpi@xxxxxxxxxxxxxxx; linux- > pm@xxxxxxxxxxxxxxx; dave.hansen@xxxxxxxxxxxxxxx; bp@xxxxxxxxx; > tglx@xxxxxxxxxxxxx; andi@xxxxxxxx; puwen@xxxxxxxx; peterz@xxxxxxxxxxxxx; > rui.zhang@xxxxxxxxx; gpiccoli@xxxxxxxxxx; daniel.lezcano@xxxxxxxxxx; > Narayan, Ananth <Ananth.Narayan@xxxxxxx>; Shenoy, Gautham Ranjal > <gautham.shenoy@xxxxxxx>; Ong, Calvin <Calvin.Ong@xxxxxxx>; > stable@xxxxxxxxxxxxxxx; regressions@xxxxxxxxxxxxxxx > Subject: Re: [PATCH] ACPI: processor_idle: Skip dummy wait for processors > based on the Zen microarchitecture > > On 9/22/22 10:48, Limonciello, Mario wrote: > > > > 2) The title says to limit it to old intel systems, but nothing about this > actually enforces that. > > It actually is limited to all Intel systems, but effectively won't be used on > anything but new > > ones because of intel_idle. > > > > As an idea for #2 you could check for CONFIG_INTEL_IDLE in the Intel case > and > > if it's not defined show a pr_notice_once() type of message trying to tell > people to use > > Intel Idle instead for better performance. > > What does that have to do with *this* patch, though? It was just a thought triggered by your commit message title. > > If you've got CONFIG_INTEL_IDLE disabled, you'll be slow before this > patch. You'll also be slow after this patch. It's entirely orthogonal. > Yeah it's orthogonal, but with this discussion happening and the code is changing /anyway/ then a pr_notice_once() seemed like a nice way to guide people towards intel_idle at the same time so they didn't trip into the same problem AMD systems do today. > I can add a "Practically" to the subject so folks don't confuse it with > some hard limit that is being enforced: > > ACPI: processor idle: Practically limit "Dummy wait" workaround to > old > Intel systems That works. > > BTW, is there seriously a strong technical reason that AMD systems are > still using this code? Or is it pure inertia? Maybe a better question for Ananth and Prateek to comment on.
