A patch series posted to the Linux kernel mailing list on September 1, 2026 does something the kernel usually avoids: it writes three CPU frequencies directly into the source. Zen 6 client parts use ACPI CPPC differently from previous AMD platforms, and the scheduler needs the maximum frequency of each core type to compute capacity. ACPI has no interface for reading that yet. So until a future specification revision adds one, the kernel carries hard coded values of 5025 for performance cores, 3524 for efficiency cores and 2399 for the new low power core type. That last number is the interesting one, because it is the first public figure of any kind for a core type AMD has not yet shipped.
The short answer
AMD posted Linux patches on September 1, 2026 adjusting ACPI CPPC handling for Zen 6 client processors. Those parts use CPPC differently from previous AMD platforms, and the kernel needs a maximum frequency per core type to compute scheduler capacity. ACPI does not yet expose that, so the patches hard code 5025 for performance cores, 3524 for efficiency cores and 2399 for a new low power core type, applied across all Zen 6 clients in the Model 80 series. The low power core therefore sits at 0.68 times the efficiency core and 0.47 times the performance core. For Zen 6 and newer the boost ratio is also computed from frequencies rather than from the abstract CPPC performance scale. Too late for 7.3, so Linux 7.4 at the earliest.
Kernel developers do not put magic constants in source files if they can avoid it. When one shows up, it is usually the visible edge of a gap between what hardware does and what a standard has gotten around to describing. A patch series posted on September 1, 2026 puts three of them in, and the reasoning behind them is a small tour of how CPU scheduling actually works.
What CPPC gives the kernel, and what it stopped giving
CPPC is the ACPI mechanism through which an operating system and a platform negotiate CPU frequency and power scaling. Rather than the OS naming a frequency in megahertz, it expresses requests on an abstract performance scale, and the platform decides what to actually do about it. That abstraction is the point. It lets one kernel interface work across vendors whose frequency behaviour differs wildly, and it lets firmware apply thermal and power constraints the OS cannot see.
AMD parts have supported CPPC for years. Zen 6 client processors, according to the patch series, use it differently from previous platforms, and the difference has a consequence: the kernel can no longer work out the maximum frequency of a given core type from what CPPC reports.
That sounds like a detail until you ask what the number was for.
Capacity is the thing that breaks
A scheduler on a heterogeneous CPU needs a shared scale for comparing core types. Not their frequencies as such, but their relative ability to do work, so it can answer questions like whether moving a task from a small core to a big one will actually help enough to justify the migration, or whether a runqueue is overloaded relative to what that particular core can deliver.
That scale is capacity, and it is derived from the peak performance of each core type. Get it wrong and everything built on top of it inherits the error. Load balancing puts work in the wrong place. Frequency governors misjudge how loaded a core is. Energy aware placement, which explicitly reasons about performance per watt across core types, produces confident nonsense.
The patch cover text puts the problem plainly: Zen 6 client platforms use CPPC differently than previous platforms, and knowing the maximum frequency for a core type is needed for capacity calculations. Newer versions of ACPI will introduce a proper interface for getting that information, but until then values are hard coded so the systems perform as intended and to unblock future scheduler work while the wait continues.
Read that last clause again, because it is the honest part. Somebody is trying to write scheduler support for hardware that is coming whether or not the standards body finishes, and they need a number to build against.
Three core types, and a first number for the new one
The hard coded values put Zen 6 performance cores at 5025, Zen 6 efficiency cores at 3524, and the new low power core type at 2399.
The third entry is the one worth sitting with. AMD client parts have had two core types since Zen 4c brought dense cores to the picture: full performance cores and efficiency cores that trade clock speed and area for density. Zen 6 adds a third tier below both, and this patch is where a public number for it first appears.
Ratio wise, the low power core is 0.68 times the efficiency core and 0.47 times the full performance core. Roughly, it clocks at slightly under half a performance core.
Now the caveats, which matter as much as the numbers. This is one hard coded set applied to every Zen 6 client in the Model 80 series, and there is no indication of how carefully it was tuned. It is a frequency scale value, not a specification. And crucially, there is no information here at all about how much power these low power cores actually draw, which is the only figure that would tell you what they are for. A core at 0.47 times the clock is uninteresting if it uses 0.47 times the power. It is very interesting if it uses a fraction of that.
Our earlier coverage of AMD extending amd_hsmp to Zen 6 client chips tracks the other half of this preparation work, and the notes on hybrid cluster balancing in Linux 7.3 cover what the scheduler is doing with heterogeneous topologies on the Intel side.
Frequencies instead of abstract performance values
There is a second change in the series worth flagging. For Zen 6 and newer, the boost ratio is calculated from frequency values rather than from the arbitrary CPPC performance value scale.
That is a shift in approach, not just an implementation detail. The CPPC performance scale is deliberately unitless. Its contract is essentially that higher means faster, with no promise that the numbers correspond to anything measurable. Excellent for portability, useless when you need to reason about how much faster.
Moving boost ratio computation onto real frequencies gives the kernel something concrete. It also creates a dependency on having frequencies the kernel can trust, which is precisely the dependency the hard coded values are standing in for. The two halves of this patch series are the same decision viewed from two directions: the kernel wants to reason in physical units, and the interface for obtaining those units has not shipped.
What to expect, and when
The patches arrived too late for Linux 7.3, whose merge window has closed. The earliest they can be mainlined is Linux 7.4.
That is a release worth marking. Linux 7.4 is shaping up to be the important one for next generation Ryzen support, and it may land in late December 2026, which would put it in position to become this year's long term support kernel. LTS kernels are what enterprise distributions build on and what stays deployed for years, so a lot of Zen 6 machines will meet Linux for the first time through 7.4 or something derived from it.
If you are planning Zen 6 client deployments, two things follow. First, 7.4 is the kernel to track, and anything earlier will not know what to do with the third core type. Second, the capacity numbers on those machines will initially be approximations rather than firmware reported truth, which is worth remembering if scheduler placement on early Zen 6 hardware turns out to be strange in ways nobody can immediately explain.
Hard coded constants in the kernel have a way of outliving the situation that justified them. This one has a clear replacement path and a stated reason. Whether the ACPI interface arrives before or after the hardware does is the part nobody controls.
Sources and further reading
- Linux Changes For CPPC On Zen 6 Clients, Hard-Coded Default Puts Low-Power Core At 0.47x, Phoronix, September 1, 2026
- New Linux Patches Tune AMD Ryzen Zen 6 To Optimize Performance And Power Consumption, Phoronix, August 31, 2026
- ACPI Collaborative Processor Performance Control, Linux kernel documentation
- amd-pstate CPU performance scaling driver, Linux kernel documentation
Frequently asked questions
Why does the kernel need a maximum frequency per core type at all?
For capacity calculations. When a scheduler places work on a heterogeneous CPU, it needs a shared scale for comparing what different cores can do, otherwise it cannot reason about whether moving a task from one core type to another will help. That scale is derived from the relative peak performance of each core type. On previous AMD platforms the kernel got what it needed through the existing CPPC performance value scale. Zen 6 client parts use CPPC differently, and the numbers the kernel can read no longer let it work out per core type maxima. Without those numbers, capacity is wrong, and everything the scheduler builds on top of capacity is wrong too.
Why hard code rather than read the values from firmware?
Because there is currently nowhere to read them from. The patch author is explicit that newer versions of the ACPI specification will introduce a proper interface for getting the maximum frequency of a core type, and that the hard coded values exist so that these systems perform as intended and to unblock future scheduler work while the wait continues. That is a reasonable trade. The alternative is either shipping known bad capacity values or holding back scheduler development on hardware that is coming regardless. The values will be replaced with firmware reported ones once the standard catches up.
What do the three numbers actually tell us about Zen 6?
That AMD client parts are moving from two core types to three. Performance cores are hard coded at 5025, efficiency or dense cores at 3524, and a new low power core type at 2399. Ratio wise, the low power core sits at 0.68 times the efficiency core and 0.47 times the full performance core. Treat those as rough scaling hints rather than product specifications: the patch applies one hard coded set to all Zen 6 clients in the Model 80 series, and there is no indication of how carefully the values were tuned. There is also no information here about how much power the low power cores actually draw, which is the number that would tell you what they are for.
What else changes in how the boost ratio is computed?
For Zen 6 and newer, the boost ratio is calculated from frequency values rather than from the arbitrary CPPC performance value scale. That is a meaningful shift in approach. The CPPC performance scale is deliberately abstract, a unitless range whose only requirement is monotonicity, which makes it portable across vendors but useless for reasoning about anything a human would recognise as speed. Deriving the boost ratio from actual frequencies gives the kernel something concrete to work with, at the cost of needing frequencies it can trust, which is exactly the problem the hard coded values are papering over.
When does this land, and does it affect me today?
It does not affect you today unless you are working on kernel scheduler or power management code. The patches arrived too late for Linux 7.3, so the earliest they can be mainlined is Linux 7.4. That release is expected around late December 2026 and is a candidate for this year's long term support kernel, which would make it the version most enterprise distributions eventually build on. If you are planning Zen 6 client deployments, the practical takeaway is that 7.4 is the kernel to watch, and that the initial capacity numbers on those machines will be approximations rather than firmware truth.