As another effort for boosting the energy efficiency and behavior of Intel Core platforms with a mix of energy efficient "E" and performance "P" cores, a set of patches were posted Friday night for adapting [1]Energy Aware Scheduling (EAS) to the Intel P-State CPU frequency scaling driver with a focus on providing better energy efficient performance initially for Lunar Lake SoCs.

Energy Aware Scheduling provides the Linux kernel's scheduler with the ability to predict the impact of its decisions on the energy consumption of individual CPU cores. Energy Aware Scheduling was started by Arm years ago around their big.LITTLE processor designs. Now though Intel is adapting Energy Aware Scheduling to their Intel P-State driver for benefiting their own x86 hybrid core designs.

The initial "request for comments" patches sent out on Friday enable EAS for hybrid platforms without SMT/HT support -- namely for the new Intel Core Ultra 200V "Lunar Lake" processors as well as future designs.

Linux power management subsystem maintainer and Intel Linux engineer Rafael Wysocki explains with these new EAS for Intel_Pstate patches:

"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.

Thus the idea is to register a perf domain per CPU type, which currently are P-cores and E-cores, to represent the relative costs of running tasks on CPUs of each type. The states table in each of these perf domains is one-element and that element only contains the cost value, which causes EAS to compare the "E-core cost" with the "P-core cost" every time it has to make a decision, and because the "E-core cost" is lower, it will always prefer E-cores as long as there is enough spare capacity to run the given task on one of them.

The intel_pstate driver knows the type of each CPU, so it can create cpumasks requisite for registering the perf domains as per the above, but the energy model registration code needs to be adjusted to handle perf domains with one-element states tables (further referred to as stub perf domains). It also needs to allow adding a new CPU to an existing perf domain to handle the case in which some CPUs are offline to start with and are brought online later via sysfs. The first 4 patches in the series make the requisite energy model change.

Patch [5/6] updates the EAS setup code to allow it to work without the schedutil cpufreq govenor which need not be used when intel_pstate is in use (in the "active" mode, intel_pstate uses a built-in governor that can work with EAS just fine because it also adjusts the CPU performance level to utilization).

The last patch modifies intel_pstate to register the perf domains described above and update them when new CPUs become available for the first time."

No numbers were provided to quantify the resulting performance impact or the net gains for the power efficiency. But with the EAS code as mentioned set to prefer E cores for as long as there is capacity available, it will be interesting to see how this EAS + intel_pstate behaves and how nice of an experience it is for end-users for nice performance while balancing power efficiency.

Those interested can find the RFC patches for this Energy Aware Scheduling adaptation for the Intel P-State driver via [2]this patch series on the Linux power management list.



[1] https://www.phoronix.com/search/Energy+Aware+Scheduling

[2] https://lore.kernel.org/linux-pm/3607404.iIbC2pHGDl@rjwysocki.net/