systems · nullvector · 3 hours ago

Linux 6.14 ships with per-core frequency scaling that actually works

After years of the cpufreq governor being a blunt instrument, 6.14 finally ships with per-core P-state control that talks directly to the hardware interface instead of routing through the scheduler hints.

I've been running the RC for six weeks. On my 5950X, workloads that mix IO-bound and compute-bound threads now settle into sensible states without manual taskset pinning. The variance on my database benchmarks dropped from ±12ms to ±3ms under mixed load.

The key patch series is from Peter Zijlstra's cpufreq rework — it decouples utilization tracking from the frequency decision loop entirely. Each core now gets a rolling window estimate rather than sharing a global governor tick.

Benchmarks attached in the comments. Full methodology: stock kernel vs 6.14, same hardware, same workload generator, 100 runs each.

2.1k

214 comments sort: best ▾

pcie_whisperer · 2h

Can confirm. I saw the same pattern on a Zen 4 server under PostgreSQL + FFmpeg transcode mix. The governor previously kept boosting cores unnecessarily during IO wait, which caused thermal throttling on the compute cores. Now it doesn't. Simple fix with a big effect.

847

nullvector OP · 2h

Exactly this. The key insight from Zijlstra's patchset is that IO-wait CPU utilization was being counted the same as real compute utilization. Now they're split, so the governor can make the right call per core.

312

kernel_lurker · 1h

Does this interact cleanly with cgroups v2 CPU weights? We pin workloads behind cgroup quotas and I want to make sure the per-core tracking doesn't get confused by the cgroup scheduler.

pcie_whisperer · 58m

Tested this. cgroup v2 CPU weights are respected — the per-core tracking sits below the scheduler layer, so quotas still apply correctly.

thmsrwth · 2h

The variance reduction is the real headline. Latency predictability matters more than peak throughput for most server workloads. This is going in production on the next cycle.

391

void_pointer · 1h

How does this interact with AMD's preferred core technology? The BIOS reports a ranking of preferred cores per die — does the new governor respect that, or does it track its own utilization signal and potentially conflict?

167

nullvector OP · 45m

It reads the preferred core ranking from ACPI and weights frequency decisions accordingly. Tested on a 7950X — the preferred cores do get higher boost clocks for single-threaded bursts. It's not conflicting, it's composing with the existing signal.

dangerzone · 44m

Ran the same benchmark series on an Intel Raptor Lake Refresh. Results are more muted — ~15% variance reduction vs the 40% on Zen 5. Intel's hardware P-state interface has less granularity, so the governor has fewer levers to pull. Still an improvement.

134

sigint_fan · 28m

Any regression on battery life for laptops? That's always the tradeoff with more aggressive per-core boosting.