On Wed, Feb 01, 2023 at 08:02:48PM -0300, Guilherme G. Piccoli wrote: > From: Dave Hansen <dave.hansen@xxxxxxxxx> > > commit e400ad8b7e6a1b9102123c6240289a811501f7d9 upstream. > > Old, circa 2002 chipsets have a bug: they don't go idle when they are > supposed to. So, a workaround was added to slow the CPU down and > ensure that the CPU waits a bit for the chipset to actually go idle. > This workaround is ancient and has been in place in some form since > the original kernel ACPI implementation. > > But, this workaround is very painful on modern systems. The "inl()" > can take thousands of cycles (see Link: for some more detailed > numbers and some fun kernel archaeology). > > First and foremost, modern systems should not be using this code. > Typical Intel systems have not used it in over a decade because it is > horribly inferior to MWAIT-based idle. > > Despite this, people do seem to be tripping over this workaround on > AMD system today. > > Limit the "dummy wait" workaround to Intel systems. Keep Modern AMD > systems from tripping over the workaround. Remotely modern Intel > systems use intel_idle instead of this code and will, in practice, > remain unaffected by the dummy wait. > > Reported-by: K Prateek Nayak <kprateek.nayak@xxxxxxx> > Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx> > Signed-off-by: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx> > Reviewed-by: Mario Limonciello <mario.limonciello@xxxxxxx> > Tested-by: K Prateek Nayak <kprateek.nayak@xxxxxxx> > Link: https://lore.kernel.org/all/20220921063638.2489-1-kprateek.nayak@xxxxxxx/ > Link: https://lkml.kernel.org/r/20220922184745.3252932-1-dave.hansen@xxxxxxxxx > Signed-off-by: Guilherme G. Piccoli <gpiccoli@xxxxxxxxxx> > --- > > > Hi folks, seems the intention was to send this to stable [0], so here it is, > lemme know if you see any issues with that - build tested in 5.10/5.15, also > it has been running for a while on Steam Deck's kernel. Now queued up, thanks. greg k-h