Fedora’s Tuned-PPD Performance Regression Is Headed for a Kernel Fix

Fedora Workstation 44 showed unexpectedly weak performance in recent testing on Framework’s new Laptop 13 Pro with Intel Core Ultra Series 3, code-named Panther Lake. According to Phoronix, the regression is connected to Fedora’s Tuned-PPD setup and should be corrected by an upcoming Linux kernel change.

That matters because this is not the usual case of a new platform merely needing more application-specific tuning. A system-level performance policy issue can affect benchmark results, interactive responsiveness, sustained workloads, and battery-versus-performance behavior before an engineer has changed a single workload setting.

What was observed

The issue surfaced during a comparison of six Linux distributions on the Panther Lake-based Framework Laptop 13 Pro. Fedora Workstation 44 was notably slower than expected in those tests.

Phoronix identifies the Fedora Tuned-PPD arrangement as the relevant factor and reports that a new kernel should fix the regression. The available report does not establish that Panther Lake hardware itself is inherently slow under Fedora, nor does it suggest that every Fedora installation is affected in the same way. The important distinction is that the result points to a software policy interaction rather than a straightforward CPU capability problem.

For teams evaluating new Intel client hardware, that distinction is significant. Early benchmark data can easily be interpreted as a distribution-wide performance verdict when the actual cause is a policy daemon, a selected power profile, or the kernel interface used to apply it.

Why Tuned-PPD is in the path

Fedora’s power and performance management has been evolving around tuned and the power-profiles-daemon-compatible behavior commonly referred to as Tuned-PPD. In practical terms, this layer exposes power-profile choices while coordinating system tuning decisions underneath.

That is useful in principle. Desktop users need an understandable way to choose between power saving, balanced operation, and higher performance. Fleet operators also benefit when a common policy mechanism can influence processor behavior without every desktop environment or automation tool implementing its own hardware controls.

The tradeoff is that a policy layer sits between the user’s intent and the kernel’s hardware-management interfaces. If the layer makes an unsuitable choice, fails to recognize a platform correctly, or interacts poorly with a newly introduced kernel interface, the machine may not reach the expected operating point under load.

On a freshly supported processor family such as Panther Lake, those edge cases are particularly visible. New platforms arrive with new firmware behavior, new power-management expectations, and kernel support that is still being refined. A distribution can boot and function normally while still producing poor performance because the active policy is too conservative or is being applied incorrectly.

The kernel fix is the key part

The notable part of this report is that the expected remedy is a Linux kernel fix rather than a recommendation to permanently replace Fedora’s power-management stack or abandon the distribution’s default settings.

That gives administrators a clearer path: validate the behavior again after the relevant kernel lands instead of treating the initial benchmark result as final. It also means the fix may flow through Fedora’s normal kernel update process once it is available and packaged, rather than requiring each affected user to maintain a custom daemon configuration.

The report does not provide, in the supplied source material, a specific kernel version, Fedora update date, or exact patch detail. Engineers should therefore avoid pinning deployment plans to an assumed release number. “Fixed in a new kernel” is directionally useful, but it is not the same as “already fixed in every current Fedora update.”

What to check on affected systems

If you are testing Fedora Workstation 44 on this class of hardware, capture the system state before drawing conclusions from a slow run. Record the running kernel, the active power profile, BIOS and firmware versions, AC versus battery power, thermals, and whether the workload is short-burst or sustained.

It is also worth separating a regression from expected profile behavior. A power-saving profile can legitimately reduce benchmark scores. The concern here is performance that is unexpectedly low relative to comparable Linux installations or relative to the selected profile’s intended behavior.

For reproducible evaluation, keep the power source and profile constant across distribution tests. Let the system reach a stable temperature, run multiple iterations, and preserve raw results rather than relying only on a single aggregate score. On laptops, a benchmark can be skewed by charging state, cooling conditions, background package activity, display settings, or a profile change triggered during setup.

For managed fleets, do not work around this by broadly forcing an aggressive profile everywhere without measuring the cost. That can improve throughput while reducing battery life, increasing fan noise, and changing thermal behavior. A targeted temporary mitigation may be appropriate for performance-sensitive developer machines or CI runners, but it should be documented as a workaround and revisited once the kernel update arrives.

What this means in practice

This is a reminder that modern Linux performance depends on more than the scheduler and the application binary. Kernel support, firmware, power policy, and userspace profile management all participate in the result. Fedora’s poor showing in the reported Panther Lake testing appears to be a fixable Tuned-PPD-related regression, not a reason to dismiss the hardware or Fedora outright. For now, treat benchmark numbers from affected Fedora Workstation 44 systems as provisional, track incoming kernel updates, and rerun controlled tests once the fix is available.