A compiler flag lands a 6% throughput gain on the porting benchmark. You commit it, ship the sweep, and the next engineer cannot reproduce the delta. Before anyone touched the code, the machine’s CPPC state changed — and that, not the flag, moved the number. This is the failure that Collaborative Processor Performance Control (CPPC) quietly introduces into AMD porting work. CPPC is the mechanism by which modern AMD platforms hand fine-grained frequency selection to the platform firmware and the operating system’s frequency governor, rather than exposing a fixed set of discrete clock steps. When you benchmark a ported AI workload on such a machine without pinning or recording the CPPC governor state, the throughput number you measure is not a stable property of the binary and its flag set. It is a joint outcome of your code and a power-performance policy you never controlled for. The practical consequence is direct: a throughput delta you attribute to -march=znver4 or -O3 may actually be a frequency-scaling artifact. Your per-target measurement is measuring the wrong thing. What is Collaborative Processor Performance Control, and how does it differ from legacy ACPI P-states? Legacy ACPI P-state control exposed the processor as a small set of discrete performance states — P0, P1, P2, and so on — each mapped to a fixed voltage-frequency pair. The OS governor picked a P-state; the hardware ran at that clock. The model was coarse but predictable: if you knew the P-state, you knew roughly the frequency. CPPC replaces that discrete ladder with a continuous, collaborative model. Instead of the OS choosing from a handful of fixed steps, it expresses a performance request on an abstract scale, and the platform firmware — with its own view of thermal headroom, power budget, and per-core telemetry — decides the actual delivered frequency. On Linux this surfaces through the amd-pstate driver, which can run in passive mode (the schedutil or other cpufreq governor drives requests) or in active mode (amd-pstate-epp, where an energy-performance preference hint shapes firmware behavior directly). The word that matters is collaborative. Frequency is no longer something the OS dictates and the reader can read back as a constant. It is negotiated, continuously, between the kernel governor and firmware. That negotiation is sensitive to instantaneous power draw, chip temperature, and the EPP hint in force — none of which your compiler flag changed, and all of which can move between two runs of the same binary. Why can the same binary post different throughput run-to-run? Consider a straightforward AMD porting scenario. You have a ported inference path — say a transformer decode loop compiled with the AMD-oriented toolchain — and you run a benchmark harness that reports tokens per second. You run it three times. The numbers differ by several percent, run to run, with no code change between them. Under a legacy P-state model, holding the P-state fixed would largely explain that away. Under CPPC, several policy-level things are moving underneath you: The amd-pstate driver mode (passive vs epp active) determines how aggressively performance requests translate to clocks. The active governor (schedutil, performance, powersave) shapes the request the kernel issues. The energy-performance preference — performance, balance_performance, balance_power, power — biases the firmware’s delivered frequency for a given request. Boost residency depends on thermal and power headroom, which drifts as the chip warms across a sweep. Any of these can shift a benchmark result by a margin large enough to swamp a genuine compiler-flag effect. This is an observed pattern across porting engagements, not a benchmarked rate: the run-to-run variance you see on an uncontrolled CPPC machine is frequently the same order of magnitude as the flag deltas you are trying to detect. When the noise floor is the size of the signal, the measurement cannot distinguish them. The same problem lives one layer down in memory and NUMA behavior — if you are already thinking about firmware-exposed topology effects, our note on ACPI SRAT and L3 cache as a NUMA domain covers the adjacent case where a firmware table, not your code, changes the number. How does CPPC governor state contaminate a compiler-flag validation sweep? A flag-validation sweep works by comparing the same workload compiled with different flag sets and attributing the throughput difference to the flags. The entire method rests on one assumption: everything except the flags is held constant across runs. CPPC violates that assumption silently. Here is the mechanism. You compile build A with a baseline flag set and build B with, say, -march=znver4 -O3. You run A, then B. Build A runs first on a cold chip with full boost headroom; build B runs a minute later on a warmer chip whose firmware is now shaving frequency to stay in the power envelope. Build B posts a lower number. You conclude -march=znver4 regressed performance — a false regression that is entirely a thermal-and-CPPC artifact of run ordering. Reverse the order and you would have concluded the opposite. This is the trap the compiler-flag work on ported inference paths depends on avoiding: -O3, -march, and fast-math flags do move real numbers, but you can only trust the attribution if the frequency policy underneath the sweep is nailed down. For the toolchain mechanics of what those flags actually change in generated code, the GPU compilation flags reference is the companion piece; this article is about the environment those flags are measured in. The correct framing: the CPPC governor state is a benchmark input, exactly like the flag set, and it must be recorded or pinned before a sweep for the sweep’s conclusions to hold. A control checklist for CPPC before an AMD porting benchmark Use this before trusting any AMD flag-validation numbers. It is the environment-control step that precedes the sweep, not an afterthought. Step What to check Command / signal (Linux) 1. Identify the driver Is amd-pstate active, and in which mode? cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver (expect amd-pstate or amd-pstate-epp) 2. Record the governor Which cpufreq governor is driving requests? cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor 3. Pin for the sweep Set a deterministic policy for the measurement window governor to performance (or a fixed EPP), documented in the run log 4. Record the EPP What energy-performance preference is in force? cat /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference 5. Fix boost state Is boost on or off, and consistently so? cat /sys/devices/system/cpu/cpufreq/boost 6. Warm and interleave Warm the chip before timing; interleave A/B/A/B instead of all-A-then-all-B thermal steady-state + run ordering discipline 7. Re-check after Confirm the governor did not drift mid-sweep re-read step 2 signals post-run The self-contained rule: if you cannot state the driver, governor, and EPP that were in force during a benchmark, you cannot attribute the result to your code. Record all three in the run log alongside the throughput number. When is a regression a power-policy artifact rather than a code change? The tell is reproducibility under controlled ordering. Take the suspected regression and run the two builds interleaved — A, B, A, B — on a warmed chip with the governor pinned to performance and boost held to a fixed state. If the delta survives that treatment, it is a real code effect worth investigating. If it collapses or inverts, you were measuring frequency policy, not the flag. A second tell is variance structure. A genuine flag effect produces a consistent, direction-stable delta across repeats. A CPPC artifact produces a delta whose sign and magnitude track run ordering and elapsed time under load — the later runs in a batch drift lower as the chip heats. When the “regression” correlates with position in the run queue rather than with which build is being tested, the cause is thermal-and-governor drift. This distinction is why we treat CPPC state as part of the benchmarking environment, on the same footing as the input data and the harness itself. Getting it right is not exotic tuning — it is the difference between a sweep that produces actionable attribution and one that produces noise dressed as findings. The same discipline underpins any credible before-a-port measurement, which is why it sits alongside the profiling work in our guidance on what software porting actually involves. FAQ How does CPPC on AMD work? CPPC lets the OS express an abstract performance request while the platform firmware decides the actual delivered frequency, using its own view of power budget and thermal headroom. On Linux this runs through the amd-pstate driver in passive or active (epp) mode. In practice it means CPU frequency is negotiated continuously rather than fixed, so the same workload can run at different clocks from one moment to the next. What is Collaborative Processor Performance Control and how does it differ from legacy ACPI P-state control on AMD systems? Legacy ACPI P-states exposed a small ladder of discrete voltage-frequency pairs; the OS picked one and the chip ran there predictably. CPPC replaces that ladder with a continuous, collaborative model where the OS issues a performance request on an abstract scale and firmware chooses the delivered frequency. The key difference is that frequency is no longer a constant you can read back — it is negotiated between the kernel governor and firmware. Why can the same AI workload binary post different throughput numbers run-to-run when CPPC governs frequency? Because several policy-level factors move underneath the binary: the amd-pstate mode, the active governor, the energy-performance preference, and boost residency, which itself drifts as the chip warms. Any of these can shift throughput by a margin large enough to swamp a real flag effect. When the run-to-run noise is the same size as the signal you are hunting, the numbers cannot be trusted as a property of the code alone. How does CPPC governor state contaminate a per-target compiler-flag validation sweep? A sweep attributes throughput differences to flags by assuming everything else is held constant. CPPC breaks that assumption: run ordering and thermal drift mean one build runs on a cold, high-boost chip and the next on a warmer, throttled one. The resulting delta can be a false regression caused entirely by frequency policy and run order rather than by the flag under test. How should a team pin or record CPPC/governor state before benchmarking a ported AI workload? Record the scaling driver, governor, and energy-performance preference before the sweep, pin the governor to a deterministic policy (such as performance) for the measurement window, fix the boost state, warm the chip to thermal steady state, and interleave builds rather than running all of one then all of the other. Re-check the governor after the run to confirm it did not drift. If you cannot state the driver, governor, and EPP in force, you cannot attribute the result to your code. When is a throughput regression actually a power-policy artifact rather than a code or flag change? When the delta collapses or inverts under controlled, interleaved runs on a warmed chip with the governor pinned, or when the “regression” correlates with position in the run queue rather than with which build is tested. A genuine flag effect is direction-stable across repeats; a CPPC artifact tracks run ordering and elapsed time under load. Where this fits CPPC state control belongs in the environment-control step that precedes any AMD flag-validation sweep — the same step where you pin NUMA policy and warm the harness. Skipping it does not make the benchmark fail loudly; it makes the benchmark lie quietly, which is worse. If you are building a cost-and-porting assessment on AMD hardware, this checkpoint is where our [inference cost-cut work](Inference Cost-Cut Pack) starts, and it connects to the wider GPU engineering practice that treats measurement environment as a first-class variable rather than a background assumption. The open question worth carrying forward: on a machine you do not fully own — a shared CI runner, a cloud instance where firmware policy is opaque — how much of your porting benchmark can you actually pin, and what does that residual uncertainty do to the attribution you are prepared to ship?
