ACK/Cmnt: [SRU] [Jammy] [Kinetic] [PATCH 0/1] limit "Dummy wait" to old Intel

Stefan Bader stefan.bader at canonical.com
Fri Sep 30 12:39:20 UTC 2022


On 28.09.22 16:58, Jeff Lane wrote:
> 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.
> 
> Small patch cleanly picks to both Kinetic and Jammy.
> 
> 
> Dave Hansen (1):
>    ACPI: processor idle: Practically limit "Dummy wait" workaround to old
>      Intel systems
> 
>   drivers/acpi/processor_idle.c | 23 ++++++++++++++++++++---
>   1 file changed, 20 insertions(+), 3 deletions(-)
> 

I think I read somewhere about this and AMD really wanting it gone. From the 
snippet its hard to tell whether not Intel is only matching AMD but since this 
is ACPI related worst case this arm64 which probably also do not need special 
treatment.

Acked-by: Stefan Bader <stefan.bader at canonical.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20220930/17b6514e/attachment.sig>


More information about the kernel-team mailing list