← All posts

CPU frequency scaling and performance: why your server isn't running at full speed

Modern CPUs don't run at their rated speed all the time. Understanding frequency scaling, turbo boost, and power governors can unlock hidden performance on Linux servers.

Most server CPUs ship with a base clock of 2.x GHz and a turbo boost ceiling of 3.5–4.5 GHz. In practice, many production servers spend significant time far below their turbo ceiling — not because of thermal limits, but because of power governor settings.

The Linux CPU frequency governors. The kernel controls CPU frequency through a governor, configured per-core.

*performance*: Always runs at the maximum frequency. Best for latency-sensitive workloads. Highest power draw.

*powersave*: Always runs at minimum frequency. Best for idle servers or battery-constrained environments. Can be catastrophic for application performance.

*ondemand*: Scales frequency based on load. The kernel's heuristic lags behind sudden bursts by 10-50ms. Fine for most workloads.

*schedutil*: The modern replacement for ondemand, integrated with the CFS scheduler. Reacts faster to load changes. Recommended for latency-sensitive workloads that don't want the cost of the performance governor.

Check your current governor. Run: cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor or use cpupower frequency-info.

The turbo boost trap. Intel Turbo Boost and AMD Precision Boost work by temporarily running cores above base frequency when thermal and power budgets allow. In a cloud VM, boost is often limited by the hypervisor. Check: cat /sys/devices/system/cpu/intel_pstate/no_turbo. If it reads 1, turbo is disabled.

Thermal throttling. CPUs reduce frequency when they exceed their thermal design point. On a physical server, check with: sensors | grep -i temp, or dmesg | grep -i thermal. Sustained throttling usually indicates inadequate cooling or a thermal paste failure. In cloud VMs, thermal throttling is rare but does occur on overloaded physical hosts.

Setting the governor. Use cpupower frequency-set -g performance to set the performance governor on all cores, or write directly to /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor.

C-states and latency. When a core is idle, the CPU enters a low-power sleep state. Deeper C-states save more power but take longer to wake up (C1: <1μs, C6: 100-300μs). For ultra-low-latency workloads, disable deep C-states by setting intel_idle.max_cstate=1 as a kernel boot parameter.

The cpum.ai agent captures the current scaling governor and maximum CPU frequency as part of its host baseline. When diagnosing unexplained performance degradation that doesn't correlate with load, it checks for frequency scaling anomalies as a possible root cause.

See what's causing your CPU

cpum.ai turns CPU, process, disk, and memory signals into plain-English explanations with evidence.

Open cpum.ai
CPU frequency scaling and performance: why your server isn't running at full speed — cpum.ai blog | cpum.ai