Fedora Workstation 44 was the slow one in a six distribution benchmark on the Framework Laptop 13 Pro, and Phoronix published the cause on August 11, 2026. The suspect everyone assumed was an outdated Intel Thermald, since Fedora ships 2.5.9 from February 2025 while Ubuntu 26.04 LTS carries 2.5.11. Updating to Thermald 2.5.12 did not fix it. What did fix it was one command: swapping tuned-ppd for power-profiles-daemon, the daemon Fedora dropped back in Fedora 41. If you run Fedora on a recent Intel laptop, that is a five minute check with a real payoff.
The short answer
Fedora Workstation 44 ran slower than five other Linux distributions on a Framework Laptop 13 Pro with an Intel Core Ultra X9 388H. The obvious culprit was an outdated Intel Thermald, but pushing Thermald 2.5.12 as an update left the gap in place. Replacing tuned-ppd with power-profiles-daemon brought Fedora back in line with the field, in the same performance profile as the original runs.
There is a particular kind of benchmark result that is more useful than a fast number, and it is the one where a machine is inexplicably slow and somebody bothers to find out why. Phoronix published one of those on August 11, 2026, and the answer turns out to be a package swap most Fedora users have never thought about.
The setup was a Framework Laptop 13 Pro with an Intel Core Ultra X9 388H, the Panther Lake generation, running six modern Linux distributions with out of the box configuration apart from setting the performance profile. CachyOS came out fastest, which surprised nobody. Fedora Workstation 44 coming out slower than the other five did surprise people, because Fedora was on Linux 7.1 with packages broadly in line with everything else in the field.
The obvious suspect was the wrong one
Fedora Workstation 44 shipped Intel Thermald 2.5.9. Ubuntu 26.04 LTS had 2.5.11 and upstream was at 2.5.12. Thermald 2.5.9 dates from February 2025, which is a long time to sit still on a package whose entire job is knowing how specific Intel platforms want to be driven thermally.
That gap had a mundane cause. The Fedora packager for Thermald left Red Hat and the package went unmaintained. Neal Gompa filed to take the packages over under FESCo ticket 3672, writing that there are serious functionality problems with existing Thermald in Fedora stable releases on laptops released in the past year or so. He separately requested a one time update policy exception for Thermald across all Fedora branches under ticket 3673, citing broken power management control on many recent Intel machines.
So Thermald 2.5.12 went out as a Fedora 44 update, the benchmarks were rerun on a clean install with everything current, and Fedora was still behind. The obvious explanation was correct about the package being stale and wrong about it being the cause.
What actually changed the numbers
Fedora moved from power-profiles-daemon to Tuned in 2024, with Fedora 41. Most other distributions kept power-profiles-daemon. That divergence has been quietly sitting there for two years without producing an obvious problem, which is usually how this kind of thing works.
power-profiles-daemon is not installed by default on Fedora 44 but it is still in the repositories. Swapping it in with sudo dnf swap tuned-ppd power-profiles-daemon and rerunning the affected benchmarks in the same performance mode brought Fedora 44 back in line with the other distributions. Not marginally, and not in one cherry picked test: the workloads where Fedora had been the outlier came back competitive.
The affected benchmarks were the ones you would expect to be sensitive to sustained clocks rather than burst behaviour. Timed Linux kernel compilation at defconfig, Blender rendering the Junkshop scene on CPU, Embree pathtracing the Asian Dragon model, PyTorch running ResNet-50 on CPU at batch size 16. These are all several minute jobs that keep every core busy, which is exactly the regime where the difference between two power policy implementations stops being academic.
Why a shim is the right place to look for this
The mechanism worth understanding here is not Tuned being bad. It is what happens when a desktop power slider and a server tuning framework are wired together.
power-profiles-daemon does one narrow thing. It presents three profiles over D-Bus, and when the desktop selects one it sets the platform profile and the energy performance preference on the CPU accordingly. The scope is small enough that its behaviour on a new Intel laptop is largely determined by what the kernel and firmware expose.
Tuned is a different animal. It is a general tuning framework that applies whole profiles worth of settings: sysctl values, scheduler parameters, disk readahead, CPU governor and EPP policy, all declared in profile files that were written to be reasonable across a wide range of machines. tuned-ppd is the compatibility layer that lets Tuned answer the power-profiles-daemon interface so GNOME's power controls keep functioning.
Both of those are defensible designs. The failure mode is at the seam. The desktop says performance, the shim hands that to a Tuned profile, and the profile applies a set of decisions that were tuned for a broad hardware family rather than for the specific energy performance preference behaviour that a Panther Lake part wants. Nothing is broken in a way that logs an error. The machine just runs slower than the identical hardware does under a different distribution.
What we would do on a Fedora laptop this week
Start by finding out what you are actually running, because a surprising number of people do not know. tuned-adm active tells you which Tuned profile is applied. rpm -q tuned-ppd power-profiles-daemon tells you which implementation owns the D-Bus interface. Neither command changes anything and both take a second.
If you are on a recent Intel laptop and the machine feels slower than the specifications suggest under sustained load, do the swap and measure something real before and after. A kernel build with time make -j$(nproc) is a fine proxy and it is a workload you probably run anyway. Watch clocks during the run with turbostat or a simple read of /proc/cpuinfo if you want to see the mechanism rather than just the outcome.
Make sure your Thermald is current regardless. The 2.5.12 update is a genuine fix for genuine problems on recent Intel hardware, and the fact that it did not explain this particular slowdown does not make it optional. Two separate things were wrong here, and only one of them was the headline.
We covered the kernel side of Panther Lake power behaviour when Linux stopped writing HWP request values for these chips, which is the same theme from the other direction: modern Intel silicon increasingly wants to be left to manage itself. The AMD equivalent showed up in our look at amd-pstate EPP and boost behaviour.
Sources and further reading
- Analyzing Fedora's Slow Performance On The Framework Laptop 13 Pro With Intel Panther Lake, Phoronix, August 11, 2026
- Benchmarking Six Linux Distributions On The Framework Laptop 13 Pro, Phoronix
- FESCo ticket 3672, non-responsive maintainer request for Thermald
- FESCo ticket 3673, update policy exception request for Thermald
- Fedora 41 switching from power-profiles-daemon to Tuned, Phoronix
Frequently asked questions
What is the difference between tuned-ppd and power-profiles-daemon?
They solve the same problem from opposite directions. power-profiles-daemon is a small service with one job: expose three profiles to the desktop, translate the selected one into platform profile and energy performance preference settings, and stay out of the way. Tuned is a much older and much larger Red Hat tuning framework that applies whole bundles of sysctl values, scheduler knobs, disk settings and CPU governor policy from declarative profiles. tuned-ppd is a compatibility shim that makes Tuned answer the power-profiles-daemon D-Bus interface so GNOME's power slider keeps working. The shim is where the mismatch lives: the desktop asks for performance, and what Tuned does with that request is defined by a profile that was written for a broad family of machines rather than for the specific silicon in front of it.
How do I switch my own Fedora machine, and is it reversible?
It is a single dnf transaction and it is fully reversible. Run `sudo dnf swap tuned-ppd power-profiles-daemon`, then reboot or restart the service, and confirm with `powerprofilesctl get` that the daemon is answering. To go back, run the swap in the other direction. Because both packages own the same D-Bus name, you cannot run them at once, which is exactly why dnf models this as a swap rather than an install. Nothing in your home directory or your GNOME settings changes: the power slider in the shell keeps working either way, it just talks to a different implementation underneath.
Does this affect servers, or only laptops?
The specific finding is a laptop finding, because it involves the platform profile and energy performance preference plumbing that mobile Intel parts expose and that desktops and servers largely do not use the same way. But the broader lesson travels. Tuned on a server applies a profile too, and `throughput-performance` versus `balanced` is a real difference on a database host. If you inherited a Fedora or RHEL server and have never run `tuned-adm active`, you do not currently know what tuning policy your machine is under. That is worth ten seconds of your time regardless of what this particular benchmark showed.
Why was Fedora shipping a Thermald from February 2025?
A packaging failure rather than a technical decision. The Fedora maintainer for Thermald left Red Hat and the package went unmaintained, which is the situation the project's non-responsive maintainer process exists to unblock. Red Hat contributor Neal Gompa filed to take over the packages under FESCo ticket 3672, and separately requested a one-time update policy exception for Thermald across all Fedora branches under ticket 3673, on the grounds that power management control is broken on many Intel laptops released in the past couple of years. Thermald 2.5.12 has since been pushed as a Fedora 44 update. It is a genuine fix, just not the fix for this particular slowdown.
Should I read this as Fedora being bad on new hardware?
No, and the shape of the result argues against that reading. Fedora 44 was on Linux 7.1 with packages broadly in line with the other distributions tested, so this was not a case of stale software across the board. It was one daemon making a different decision than the daemon five other distributions ship. That is a configuration divergence with a one command remedy, not a platform problem. The useful takeaway is narrower and more practical: when a machine is slower than it should be and the kernel and firmware are current, look at what is actively managing your CPU's power policy before you look anywhere else.