mbox series

[v1,0/5] x86/smp: Restore the elimination of mwait_play_dead_cpuid_hint()

Message ID 2226957.irdbgypaU6@rjwysocki.net
Headers show
Series x86/smp: Restore the elimination of mwait_play_dead_cpuid_hint() | expand

Message

Rafael J. Wysocki June 5, 2025, 3:03 p.m. UTC 
Hi Everyone,

The purpose of this series is to reapply the code changes from commit
96040f7273e2 ("x86/smp: Eliminate mwait_play_dead_cpuid_hint()") that
has been reverted because of an issue introduced by it.  This takes
place in the last patch ([5/5]) and the previous patches make
preparatory changes needed to avoid breaking systems in the field
once again.

The problem with commit 96040f7273e2 was that on SMT-capable systems
booting with "nosmt" in the kernel command line, the "dead" SMT siblings
were stuck in idle state C1 after initialization because they were
initialized before a proper cpuidle driver for the given platform got
ready.  That prevented the whole processor from entering deep package
C-states later on and pretty much ruined idle power (including power
in suspend-to-idle).

To prevent that from happening, patches [1-4/5] use the approach that
has been used for some time to address an analogous issue during resume
from hibernation, in which case the "dead" SMT siblings are also in C1
when the image kernel gets control back and they need to be put into
sufficiently deep C-states.  Namely, they are taken online and then
back offline immediately to make that happen.

The general idea is to take the "dead" SMT siblings online and then
back offline immediately when a proper cpuidle driver gets ready, but
some changes are made to avoid doing that twice in a row in vain.
For this purpose, the intel_idle driver initialization is pushed
to an earlier initialization phase (patch [1/5]) and the ACPI
processor driver only "rescans" the "dead" SMT siblings when
the ACPI idle driver is the current cpuidle driver.  It also
avoids doing this on architectures other than x86 (patch [4/5]).

Thanks!