Intel P-State Energy Aware Scheduling Patches Updated For Lunar Lake

[phoronix]

Phoronix: Intel P-State Energy Aware Scheduling Patches Updated For Lunar Lake

As covered last month on Phoronix, Intel has been experimenting with Energy Aware Scheduling (EAS) for the Intel P-State driver with a goal of enhancing the power efficiency of Core Ultra "Lunar Lake" processors. Recently a second iteration of that work was posted for review ahead of possible inclusion in a future version of the Linux kernel...

https://www.phoronix.com/news/Intel-P-State-EAS-Lunar-Lake

[pWe00Iri3e7Z9lHOX2Qx]

At this stage the Intel P-State EAS focus is on "hybrid platforms without SMT"... Which for now basically means Lunar Lake for its mix of P and E cores without any SMT / Hyper Threading support.

And Arrow Lake desktop and likely every new consumer generation for a while no?

[unwind-protect]

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

That's nice but how do they figure when a given task could (and should) run faster than that E-core level?

[yump]

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

That's nice but how do they figure when a given task could (and should) run faster than that E-core level?

Presumably the same or similar way they figure out when a given task could and should run faster than the current frequency in schedutil -- by always leaving 20% headroom. (EDIT: Nope. Apparently those schedutil changes were based on other recent changes to sched_fits_capacity()).

YMMV on how well this works. I think there have been schedutil changes since the last time Michael tested it.