Intel Continues Exploring Energy Aware Scheduling For Hybrid CPUs Without SMT
([Intel] 3 Hours Ago
Intel P-State EAS)
- Reference: 0001541150
- News link: https://www.phoronix.com/news/Intel-P-State-EAS-Hybrid-Cont
- Source link:
While Intel's Core Ultra 200V "Lunar Lake" SoCs with on-package memory has been reported to be a one-off design, besides the integrated memory it was also notable for being a hybrid core design while lacking Hyper Threading (HT / SMT) support. The notion of hybrid P/E core CPUs without SMT looks like it will continue with Intel software engineers still exploring [1]Energy Aware Scheduling (EAS) around such layouts.
As I first reported on last year, Intel engineers have been exploring [2]Linux's Energy Aware Scheduling for their P-State driver to benefit Lunar Lake . EAS was born out of Arm's big.LITTLE efforts and adapting that open-source code for Intel processors has shown of possible benefit for P/E core processors lacking SMT/HT.
It's been a few months since [3]the prior round of Intel P-State EAS patches while out today is a fresh series that has also graduated from the "request for comments" stage. Intel engineer and Linux PM/ACPI maintainer Rafael Wysocki is still requesting the Linux community to conduct further testing on these patches but things are looking up at least. Wysocki commented on today's patches:
"This is a new version of
https://lore.kernel.org/linux-pm/ [4][email protected] /
which is not regarded as RFC any more. It appears to be better than
https://lore.kernel.org/linux-pm/ [5][email protected] /
but still requires more testing, so I'd appreciate any help here.
The following paragraph from the original cover letter still applies:
"The underlying observation is that on the platforms targeted by these changes, Lunar Lake at the time of this writing, the "small" CPUs (E-cores), when run at the same performance level, are always more energy-efficient than the "big" or "performance" CPUs (P-cores). This means that, regardless of the scale-invariant utilization of a task, as long as there is enough spare capacity on E-cores, the relative cost of running it there is always lower."
The first 3 patches have been updated since v0.3 and they now depend on the new cpufreq material in linux-next.
The next 2 patches (Energy Model code changes) have been reviewed in the meantime, but they are only needed for the last 3 patches.
Patch [6/8] is essentially the same as before. It causes perf domains to be registered per CPU and in addition to the primary cost component, which is related to the CPU type, there is a small component proportional to performance whose role is to help balance the load between CPUs of the same type.
This is done to avoid migrating tasks too much between CPUs of the same type, especially between E-cores..."
We'll see where [6]the new patch series ends up and if it proves advantageous to merge this Energy Aware Scheduling support for Intel hybrid CPUs without SMT.
[1] https://www.phoronix.com/search/Energy+Aware+Scheduling
[2] https://www.phoronix.com/news/Intel-P-State-EAS-Experimental
[3] https://www.phoronix.com/news/Intel-P-State-EAS-Lunar-Lake
[4] https://www.phoronix.com/cdn-cgi/l/email-protection
[5] https://www.phoronix.com/cdn-cgi/l/email-protection
[6] https://lore.kernel.org/lkml/3344336.aeNJFYEL58@rjwysocki.net/
As I first reported on last year, Intel engineers have been exploring [2]Linux's Energy Aware Scheduling for their P-State driver to benefit Lunar Lake . EAS was born out of Arm's big.LITTLE efforts and adapting that open-source code for Intel processors has shown of possible benefit for P/E core processors lacking SMT/HT.
It's been a few months since [3]the prior round of Intel P-State EAS patches while out today is a fresh series that has also graduated from the "request for comments" stage. Intel engineer and Linux PM/ACPI maintainer Rafael Wysocki is still requesting the Linux community to conduct further testing on these patches but things are looking up at least. Wysocki commented on today's patches:
"This is a new version of
https://lore.kernel.org/linux-pm/ [4][email protected] /
which is not regarded as RFC any more. It appears to be better than
https://lore.kernel.org/linux-pm/ [5][email protected] /
but still requires more testing, so I'd appreciate any help here.
The following paragraph from the original cover letter still applies:
"The underlying observation is that on the platforms targeted by these changes, Lunar Lake at the time of this writing, the "small" CPUs (E-cores), when run at the same performance level, are always more energy-efficient than the "big" or "performance" CPUs (P-cores). This means that, regardless of the scale-invariant utilization of a task, as long as there is enough spare capacity on E-cores, the relative cost of running it there is always lower."
The first 3 patches have been updated since v0.3 and they now depend on the new cpufreq material in linux-next.
The next 2 patches (Energy Model code changes) have been reviewed in the meantime, but they are only needed for the last 3 patches.
Patch [6/8] is essentially the same as before. It causes perf domains to be registered per CPU and in addition to the primary cost component, which is related to the CPU type, there is a small component proportional to performance whose role is to help balance the load between CPUs of the same type.
This is done to avoid migrating tasks too much between CPUs of the same type, especially between E-cores..."
We'll see where [6]the new patch series ends up and if it proves advantageous to merge this Energy Aware Scheduling support for Intel hybrid CPUs without SMT.
[1] https://www.phoronix.com/search/Energy+Aware+Scheduling
[2] https://www.phoronix.com/news/Intel-P-State-EAS-Experimental
[3] https://www.phoronix.com/news/Intel-P-State-EAS-Lunar-Lake
[4] https://www.phoronix.com/cdn-cgi/l/email-protection
[5] https://www.phoronix.com/cdn-cgi/l/email-protection
[6] https://lore.kernel.org/lkml/3344336.aeNJFYEL58@rjwysocki.net/
Valeintin