Rafael Wysocki has posted a patch that changes how intel_pstate talks to Intel processors with Dynamic Efficiency Control, the power management feature arriving with Core Ultra Series 3 Panther Lake. Today the driver writes a desired performance value into MSR_HWP_REQUEST. On a DEC capable part, Wysocki says doing that may end up confusing the processor firmware, so the patch sets the field to zero and lets the firmware pick the operating point itself. It is queued for the Linux 7.3 merge window and no benchmark numbers were published with it, which is worth saying plainly.
The short answer
Rafael Wysocki has posted a patch making intel_pstate set the desired performance field of MSR_HWP_REQUEST to zero on processors with Dynamic Efficiency Control, the feature arriving with Core Ultra Series 3 Panther Lake. His reasoning is that writing a specific target may confuse the processor firmware, and that leaving it at zero lets the firmware work out the most suitable performance level itself. It targets Linux 7.3 and ships with no published measurements.
Two decades of CPU frequency work on Linux can be summarised as the kernel gradually admitting it is the wrong place to make this decision. Here is another step.
Rafael Wysocki, who maintains the power management side of the kernel, has posted a patch changing how intel_pstate behaves on processors that support Dynamic Efficiency Control. DEC is a light workload power feature arriving with Core Ultra Series 3, the Panther Lake generation. The change is small and specific: on a DEC capable part, the driver will write zero into the desired performance field of MSR_HWP_REQUEST instead of a computed target.
Wysocki's stated reason is that writing a value there may result in confusing the processor firmware, and that setting the preference to zero lets the firmware figure out the most suitable performance level by itself.
The field being surrendered
It helps to be precise about which knob this is, because HWP has several and they do different jobs.
When the kernel talks to a processor running Hardware P-States, it writes a request register that carries a minimum, a maximum, an energy versus performance preference, and a desired value. The first three are constraints, boundaries inside which the processor is free to operate. The desired field is not a boundary. It is an instruction, and writing it narrows the processor's freedom to a point.
Zero in that field is the defined way of declining to have an opinion. The processor takes the constraints and picks the operating point. On a part where the firmware is running its own efficiency logic, that is the arrangement most likely to produce what the firmware was designed to produce.
What this does not tell us
No performance or power figures were published with the patch. We think that matters enough to say twice, because the temptation with a change like this is to write it up as a battery life improvement and let readers assume a number exists.
The framing in the patch is correctness. The kernel was sending something that could confuse firmware, and it will stop. Firmware that is not being confused generally does better than firmware that is, so the expected direction is favourable. Expected direction is not a measurement, and on modern mobile parts the actual outcome depends enormously on the workload, the platform's power limits and what the OEM did with the firmware.
It also sat under review for the 7.3 merge window rather than confirmed in it. Patches at that stage usually land, and sometimes they do not.
Who should care now
Almost nobody, and that is fine.
If you run Panther Lake hardware on Linux, the useful action is to note your current kernel and to revisit power behaviour once you are on 7.3 or later, because the driver will be doing something different underneath you. Measuring before and after on your own workload is worth more than any general claim, including ours.
If you run anything older, this patch does not touch your machines. The frequency scaling knobs you had last week are the ones you have now.
The wider point is the one worth carrying away. On Intel mobile parts, the balance of control has been shifting toward the processor for years, and each of these patches moves a little more of the decision out of the kernel. That is mostly good for power outcomes and mostly frustrating for anyone who wants to reason about why a machine chose a frequency, because the reasoning increasingly happens in firmware nobody outside Intel can read.
Sources and further reading
- Linux to avoid confusing processor firmware with newer Intel CPUs sporting DEC, Phoronix, August 2026
- The intel_pstate CPU performance scaling driver, kernel documentation
- CPU performance scaling, kernel documentation
- The Linux PM mailing list archives
Frequently asked questions
What is the desired performance field in MSR_HWP_REQUEST?
Hardware P-States, HWP, moves frequency selection from the operating system into the processor. The kernel stops picking exact frequencies and instead writes a request register describing what it wants: a minimum performance floor, a maximum ceiling, an energy versus performance preference, and a desired value. The first three are constraints. The desired field is different, because it is a specific target rather than a bound, and writing it takes back some of the autonomy HWP was designed to give the processor. Leaving it at zero is the documented way of saying no opinion, choose for yourself, which is exactly what this patch does on DEC capable parts.
What is Dynamic Efficiency Control?
It is a newer Intel power management capability aimed at light workloads, arriving with Core Ultra Series 3, the Panther Lake generation. The short version is that the processor firmware makes finer grained decisions about how to serve small amounts of work efficiently rather than racing to a high frequency and back. Public technical detail is still thin, and we are not going to pretend otherwise. What the patch tells us is behavioural: the firmware is doing enough of its own reasoning that a specific performance target from the kernel can work against it rather than with it.
Do I need to change anything on my own machines?
No. This is a kernel side change that applies only on hardware advertising DEC support, and it needs no configuration from you. If you are running Panther Lake on Linux, the thing to do is note which kernel you are on and revisit power behaviour after you move to 7.3 or later, because that is when the driver behaviour changes underneath you. On everything older, nothing about this patch touches your system. Frequency scaling on Intel remains the same set of knobs it was last week.
Will this make my laptop use less power?
Unknown, and nobody has published a figure. The patch is framed as correctness rather than as an optimisation: it stops the kernel from sending a signal that may confuse the firmware, and firmware that is not confused generally behaves better than firmware that is. That is a reasonable expectation, not a measurement. If battery life on Panther Lake matters to you, the honest advice is to measure your own workload across the kernel change rather than assuming a direction, because power outcomes on modern parts depend heavily on what the machine is actually doing.
How do I see what my machine is doing with frequency scaling today?
Start with which driver is in charge, because the answer changes everything downstream. Read scaling_driver under the cpufreq directory in sysfs. If it reports intel_pstate you are in the driver this patch touches, and the energy performance preference exposed there is the knob with the most real effect on most systems. If it reports acpi-cpufreq you are on a different path entirely. Beyond that, turbostat is the tool that shows you what actually happened rather than what was requested, which is the distinction that matters once firmware is making the decisions.