AMD Patches Linux to Read CPU Boost Frequency Directly, Bypassing Estimation

AMD is preparing a meaningful improvement to how operating systems understand CPU boost behavior on modern Ryzen and EPYC processors. A five-patch series submitted to the Linux kernel mailing list by AMD engineer Mario Limonciello on May 4, 2026 introduces support for a new CPPC HighestFreq register — a hardware field that allows firmware to directly report each CPU core’s maximum achievable frequency to the operating system, instead of requiring the OS to estimate it.

The Problem: Linear Interpolation Falls Short

Modern AMD processors use CPPC — Collaborative Processor Performance Control — as the mechanism through which firmware and the operating system cooperate on performance decisions. Rather than selecting from a fixed menu of clock speeds (as older P-state systems did), CPPC communicates abstract “performance” values that the OS then interprets to manage frequency and power.

The catch is that these performance values do not always translate cleanly into real clock speeds. On some Ryzen systems, the relationship between a core’s CPPC performance value and its actual operating frequency is not linear across all cores on the same chip. The OS currently bridges this gap through linear interpolation — an estimation method that works well when the mapping is uniform, but introduces inaccuracy when it is not.

The Fix: A Register That Tells the Truth

The CPPC HighestFreq register is AMD’s answer. When present, it allows firmware to expose each core’s true maximum frequency directly — no guesswork, no interpolation. The patch series updates existing CPPC definitions to align with the current ACPI 6.6 specification and then adds forward-looking support for the proposed ACPI 6.7 register.

Critically, the implementation is designed to be optional and non-breaking. If the HighestFreq value is present in the firmware ACPI table, the kernel uses it for more accurate CPU capacity calculations and boost-ratio determination. If it is absent — as it will be on older hardware and OEM configurations that do not include it — existing behavior is preserved unchanged. Both the amd-pstate driver path and the older acpi-cpufreq path benefit from the new value when it is available.

Why It Matters for Task Scheduling

The practical significance lies in the scheduler’s ability to make better core-selection decisions. Modern Ryzen CPUs already rely on a “preferred core” mechanism — because semiconductor manufacturing variation means individual cores on the same chip have slightly different peak boost capabilities, the OS must know which cores can sustain the highest frequency in order to route latency-sensitive workloads (like gaming or single-threaded tasks) to the best available core.

Without accurate frequency data, the scheduler can still make reasonable decisions most of the time — but not optimal ones every time. On bursty or lightly threaded workloads, this can affect which core gets the task and how quickly the platform reaches an efficient boost state. With HighestFreq, the OS receives ground truth from firmware, enabling more precise scheduling and capacity modeling.

What About Windows 11?

Windows 11 also uses CPPC data for boost behavior and preferred-core scheduling, so this improvement is architecturally relevant to it as well. However, this Linux kernel patch has no direct effect on Windows. The ACPI 6.7 specification has not yet been formally ratified; the register is currently a proposal under review by the ACPI Specification Working Group (ASWG).

Should ACPI 6.7 officially include the HighestFreq register, and should AMD include it in future processor firmware, Windows 11 could gain access to the same accurate frequency data — but only if Microsoft independently adds corresponding support to its own scheduler and CPPC handling. That outcome is plausible but remains speculative at this stage.