Linux Patches Aim To Further Lower Intel Sierra Forest Idle Power Use
A set of patches are currently under review on the Linux kernel mailing list for helping to further lower idle power use for Xeon 6 Sierra Forest processors.
Intel engineer Patryk Wlazlyn has a set of three patches to the "intel_idle" Linux driver for helping to ensure the Sierra Forest processors can hit their deepest C states while idle.
Wlazlyn explains in the patch series:
Surprisingly this Sierra Forest C state issue wasn't noticed and fixed months ago. These patches are now under review and given the timing and their relatively small change, hopefully will be deemed ready in time for the upcoming Linux v6.13 kernel cycle.
Intel engineer Patryk Wlazlyn has a set of three patches to the "intel_idle" Linux driver for helping to ensure the Sierra Forest processors can hit their deepest C states while idle.
Wlazlyn explains in the patch series:
The current implementation for looking up the mwait hint for the deepest cstate depends on them to be continuous in range [0, NUM_SUBSTATES-1]. While that is correct on most Intel x86 platforms, it is not architectural and may not result in reaching the most optimized idle state on some of them.
For example Intel's Sierra Forest report two C6 substates in cpuid leaf 5:
C6S (hint 0x22)
C6SP (hint 0x23)
Hints 0x20 and 0x21 are skipped entirely, causing the current implementation to compute the wrong hint, when looking for the deepest
cstate for offlined CPU to enter. As a result, package with an offlined CPU can never reach PC6.
Allow the idle driver to communicate the deepest idle cstate to the x86 offline code.
...
On Sierra Forest the mwait hints for subsequent idle states are not continuous, resulting in play_dead() code not computing the most optimized idle state when CPU is put offline. This in turn prevents from entering PC6 state when any of the CPUs in the package is offline. Force the known, best mwait hint for the deepest cstate.
Surprisingly this Sierra Forest C state issue wasn't noticed and fixed months ago. These patches are now under review and given the timing and their relatively small change, hopefully will be deemed ready in time for the upcoming Linux v6.13 kernel cycle.
1 Comment