Computer performance does not depend entirely on processor specifications.

It also depends on how effectively the operating system distributes work across available CPU cores.

That decision has become increasingly complicated on modern processor architectures.

Some processors combine different classes of CPU cores with different frequency limits and cache arrangements.

The Linux kernel must balance competing goals: selecting the fastest available core, avoiding unnecessary task migrations and keeping data close to the processing units that use it.

Those goals sometimes conflict.

That is precisely what happened in a performance regression documented on AMD's Ryzen AI 9 HX 370 and covered by Phoronix on October 26, 2026.

A scheduler optimization intended to improve cache locality could take precedence over moving demanding workloads to faster cores.

The correction is now part of Linux 7.4 development.

Ryzen AI 9 HX 370 combines two types of CPU cores

AMD's Ryzen AI 9 HX 370 belongs to the Strix Point processor family.

It features twelve physical CPU cores and twenty-four threads.

Four cores use the conventional Zen 5 architecture, while eight are based on the more compact Zen 5c design.

The two core types share many architectural features, but their operating frequency limits and cache arrangements differ.

On the configuration described in the technical report, the Zen 5 cores can reach approximately 5.1GHz.

The Zen 5c cores are limited to about 3.3GHz.

Their associated L3 cache domain is also smaller: 8MB rather than the 16MB associated with the Zen 5 cores.

These differences do not make Zen 5c cores undesirable.

They allow AMD to include more computing resources within the physical and power constraints of a mobile processor.

However, a workload that is sensitive to maximum clock speed and cache capacity may run significantly faster on a Zen 5 core.

The operating system must recognize when such a move is beneficial.

When a cache optimization becomes counterproductive

The regression concerns a Linux scheduling feature called Cache Aware Scheduling.

Its purpose is to consider CPU cache topology when assigning tasks.

When a program runs on a core, some of its data may remain in different levels of the processor cache hierarchy.

If the task moves to a core outside its previous shared cache domain, some data may need to be fetched again.

That can add latency and increase memory traffic.

Avoiding unnecessary migrations is therefore generally useful.

Cache Aware Scheduling attempts to preserve that locality.

However, the cost of migration may sometimes be smaller than the performance benefit of running on a faster CPU core.

On the Ryzen AI 9 HX 370, the scheduler could keep a demanding task within the Zen 5c core group simply to preserve cache locality.

Faster Zen 5 cores could remain available at the same time.

An optimization that makes sense in one situation could therefore create a regression in another.

Clang compilation revealed the problem

The issue was initially reported by Klaus Kusche, a Gentoo Linux user.

He observed slower compilation performance with LLVM Clang when using full link-time optimization.

Link-Time Optimization, or LTO, allows the compiler to analyze multiple program components during the final linking process.

It can improve the resulting program's performance, but may require substantial computing resources during the build.

Full-LTO workloads can be particularly demanding.

They may consume significant memory, place pressure on CPU caches and keep individual cores busy for extended periods.

On the affected machine, these tasks could start on Zen 5c cores and remain there even when faster cores were available.

The differences in clock speed and cache capacity combined to produce a substantial slowdown.

The user observed much worse compilation performance compared with kernels that did not exhibit the same behavior.

This was a specific reproducible workload described in kernel development discussions, not evidence that every Linux program experienced the same regression.

Two scheduling strategies were producing conflicting decisions

Understanding the fix requires distinguishing two Linux scheduling mechanisms.

The first is Cache Aware Scheduling.

It attempts to avoid unfavorable migrations between cache domains, particularly when tasks benefit from good memory locality.

The second is asymmetric packing.

This mechanism recognizes performance priorities among available processors and favors higher-priority cores when appropriate.

On systems containing cores with different performance characteristics, the two policies do not always recommend the same destination.

Cache Aware Scheduling may favor keeping a task within its current core group.

Asymmetric packing may instead prefer moving it to a faster core.

The regression occurred because the cache locality policy could override the latter decision.

The scheduler would preserve a potential cache benefit while sacrificing a larger gain in processing performance.

The patch prioritizes faster available cores

Kernel developer Tim Chen proposed a change to resolve the conflict.

When asymmetric packing identifies an idle core with higher priority, the cache locality policy should no longer automatically block migration.

In that situation, the advantage of a faster core can take precedence over the potential cost of moving between cache domains.

The patch modifies the decisions made during regular and active load balancing.

It therefore changes the conditions under which tasks are allowed to migrate.

The objective is not to move every task onto Zen 5 cores.

It is to prevent a cache-locality rule from blocking beneficial placement when higher-performance resources are available.

The approach preserves Cache Aware Scheduling in situations where its optimizations remain appropriate.

This is a targeted correction of scheduling priorities, not the removal of an entire feature.

The issue was not simply incorrect CPU clock management

The difference between 3.3GHz and 5.1GHz might suggest that the problem was caused by faulty CPU frequency management.

In reality, the issue was different.

The system was not necessarily forcing a fast Zen 5 core to operate at an unusually low clock speed.

Instead, it could leave work on a different core with less favorable characteristics for that particular workload.

The distinction matters during troubleshooting.

A CPU frequency governor and an operating system scheduler perform different functions.

The first helps determine processor frequency and power states.

The second determines which work runs on which logical processor.

Changing a power governor does not automatically fix this type of task-placement problem.

The Linux correction addresses the scheduling decision itself.

Why the fix matters to software developers

Software compilation is a useful way to expose CPU scheduling problems.

Some build stages can take advantage of many cores working in parallel.

Others depend more heavily on the execution speed of a relatively small number of tasks.

When the workload also makes intensive use of CPU cache, unfavorable placement can create multiple performance penalties.

Developers frequently using Clang, large software libraries or projects built with LTO may therefore be especially sensitive to this regression.

On distributions such as Gentoo, where software is often compiled locally, these workloads are relatively common.

That helps explain why a Gentoo user identified the problem during normal use.

However, different software projects use different compilation strategies.

The fix does not guarantee shorter build times for every program.

It addresses a specific situation in which the scheduler made an unfavorable placement decision.

An Intel engineer helped fix an AMD processor regression

One interesting aspect of the story is the origin of the patch.

The change was proposed by Tim Chen, an Intel engineer involved in Linux kernel development.

It addresses a regression documented on AMD hardware.

That kind of cross-company contribution is common in open-source development.

The Linux scheduler is shared infrastructure that must operate correctly across many processor families.

An improvement developed around one particular case may also benefit architectures with similar characteristics.

The work involved discussions with other contributors, including Klaus Kusche, who originally reported the regression.

Those exchanges enabled different patch revisions to be tested and adjustments to be made for older kernel branches.

The development process does not depend exclusively on the commercial relationship between processor manufacturers.

It relies on publicly reviewing code changes and testing them on real hardware.

Linux 7.2 and 7.3 are also expected to receive the fix

The patch has been merged into Linux 7.4 development through the scheduler fixes process.

Phoronix also reports that it is marked for backporting to the Linux 7.2 and 7.3 stable branches.

A backport adapts a correction for an older kernel version.

This allows users to benefit from a repair without necessarily upgrading to the latest mainline kernel.

It is particularly important for distributions that prioritize stability.

The technical discussions show that adapting the change to Linux 7.2 requires modifications compared with the newer implementation.

A patch developed for Linux 7.4 therefore cannot necessarily be applied unchanged to an older kernel.

Internal scheduler interfaces evolve over time.

Stable branch maintainers must verify that the change works correctly with the older codebase.

As of this report, backporting is planned. Actual availability will depend on subsequent stable releases.

Not every Ryzen AI processor is necessarily affected

The documented report specifically concerns the Ryzen AI 9 HX 370.

Phoronix suggests that other processors combining Zen 5 and Zen 5c cores might also benefit from the change.

That possibility is consistent with the general operation of the scheduler.

However, it should not be treated as an official list of affected processors.

Behavior depends on CPU topology, cache domain characteristics, kernel version and workload.

Two computers using similar processors may behave differently depending on their software configurations.

A Ryzen AI laptop is therefore not automatically slower simply because it runs Linux.

The conditions triggering the regression must be present.

Measurements from the original compilation workload cannot establish that every application is affected.

How much performance improvement should users expect?

This is probably the most important practical question.

The technical reports describe a substantial slowdown in the examined Clang full-LTO compilation workload.

However, they do not establish one universal percentage improvement across different machines and applications.

The benefit depends on cache behavior, task duration and core availability.

A workload already running on appropriate cores may not benefit from the change.

Similarly, applications that efficiently use available cores without encountering this scheduling conflict may show unchanged performance.

It would therefore be misleading to claim that Linux 7.4 makes every AMD computer faster.

The patch addresses a slowdown caused by an incorrect scheduling decision.

It does not increase the processor's intrinsic computing capability.

Could games benefit as well?

Any change to CPU scheduling naturally attracts interest from gamers.

On some hybrid architectures, task placement can influence game performance, particularly when certain workloads are CPU-limited.

However, the issue examined here was documented using a demanding compilation task.

The kernel discussions do not demonstrate a general improvement in gaming frame rates.

There is therefore no basis for promising a specific FPS increase.

Games have highly varied performance characteristics.

Some primarily depend on GPU performance, while others place greater pressure on a limited number of CPU threads.

Task distribution, cache behavior and thermal limits also matter.

Benchmarks conducted after the patch reaches production kernels would be needed to measure its impact across different games.

Should Linux users upgrade their kernel immediately?

Users who are not experiencing performance issues have no specific reason to rush into an experimental kernel upgrade because of this report.

The correction is following the normal Linux kernel development and maintenance process.

Distributions will deliver corresponding updates according to their release schedules.

Gentoo users or those running frequently updated distributions may receive the change earlier than users of enterprise-focused systems.

That does not mean more conservative distributions will ignore the problem.

They may include backported fixes without changing the kernel's main version number.

Before changing kernels, users should verify their installed version and whether their distribution has already incorporated the correction.

Manually installing an experimental kernel may introduce separate stability or compatibility risks.

For developers experiencing the regression, monitoring official stable updates and distribution patches is the more practical approach.

A small code change highlights a larger scheduling challenge

This correction illustrates a growing challenge in modern computing.

Processors increasingly contain heterogeneous resources.

Operating systems must consider core performance, data locality, energy consumption and workload distribution simultaneously.

No single placement rule is optimal in every situation.

Keeping a task close to cached data can be beneficial.

Moving it to a faster core can be even better when the performance difference outweighs the cost of migration.

That is the decision Tim Chen's patch improves.

The Ryzen AI 9 HX 370 does not lack computing resources. In the reported scenario, Linux was simply failing to assign demanding work to the most appropriate ones.

The integration of this correction into Linux 7.4, with stable backports planned, is therefore a meaningful improvement for affected configurations.

More broadly, it demonstrates why effective scheduling depends on knowing when to preserve cache locality and when to move work to a substantially faster core.