---
title: "CPU Governor: Why 'performance' Matters for Game Servers"
excerpt: "How Linux CPU frequency governors work, why ondemand costs a game server latency, and how to set the performance governor so the core runs at full clock continuously."
category: "optimization"
tags: "cpu, linux"
image: ""
read_time: "8 min read"
---
<p>A CS 1.6 server sends and services packets in bursts, hundreds of times a second, with long-ish idle gaps between them. That pattern is exactly what fools the default Linux CPU governor: it sees the idle gaps, clocks the core down to save power, and then has to ramp back up when the next packet arrives — adding latency at the worst moment. On a <a href="/tutorials/stable-1000-fps-linux-server">1000 FPS server</a> those micro-stutters show up as jitter. Switching to the <code>performance</code> governor pins the core at full clock and removes the ramp entirely.</p><h2>1. What a governor does</h2><p>The CPU frequency governor is the kernel policy that decides, moment to moment, what clock speed each core runs at. The common ones:</p><ul><li><strong><code>performance</code></strong> — hold the maximum frequency at all times. No ramp, no latency, higher idle power.</li><li><strong><code>powersave</code></strong> — hold the minimum frequency. Worst case for a game server.</li><li><strong><code>ondemand</code> / <code>schedutil</code></strong> — scale frequency up and down with load. Great for laptops, bad for bursty low-average-load servers because the burst is over before the clock has ramped.</li></ul><p>A game server's average CPU can look low even when its latency needs are high — that mismatch is precisely why load-scaling governors underserve it.</p><h2>2. Check your current governor</h2><p>Read what each core is set to:</p><pre>cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor</pre><p>Or, if <code>cpupower</code> is installed:</p><pre>cpupower frequency-info</pre><p>If you see <code>ondemand</code>, <code>schedutil</code>, or <code>powersave</code>, you are leaving latency on the table. Also read the live frequency to see the ramp in action:</p><pre>grep MHz /proc/cpuinfo</pre><h2>3. Set the performance governor</h2><p>The clean way, with the cpupower tool:</p><pre>apt install linux-tools-common linux-tools-generic # Debian/Ubuntu
cpupower frequency-set -g performance</pre><p>Or write directly to sysfs for every core, no package needed:</p><pre>for c in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do
echo performance | sudo tee "$c"
done</pre><p>Re-read the governor afterward to confirm every core now says <code>performance</code>.</p><h2>4. Make it survive a reboot</h2><p>Both methods above are lost on reboot. Persist it. On systems with the <code>cpupower</code> service, set the governor in <code>/etc/default/cpupower</code> (or the distro's cpufrequtils config) and enable the service. A simple, portable alternative is a systemd unit that writes the sysfs values at boot, or adding the <code>for</code> loop above to a startup script that runs before your game servers launch. Whatever you choose, verify after a reboot — a governor that reverts to <code>ondemand</code> overnight quietly reintroduces the jitter you fixed.</p><h2>5. Where it matters most and least</h2><p>The <code>performance</code> governor helps most on:</p><ul><li>Servers targeting high, steady FPS where jitter is visible to players.</li><li>Bare-metal and dedicated boxes where you control the host and actually own the frequency policy.</li></ul><p>It matters less — or not at all — on many VPS plans, where the <strong>host</strong> controls CPU frequency and your guest may not even expose <code>scaling_governor</code>. If <code>/sys/devices/system/cpu/cpu*/cpufreq/</code> does not exist in your VPS, frequency is the host's decision, and your real enemy there is <a href="/tutorials/cpu-steal-time-vps">steal time</a>, not the governor.</p><h2>6. Turbo, C-states and the BIOS</h2><p>The governor is only the operating-system layer of frequency control; two more knobs live below it. <strong>Turbo/boost</strong> lets a core briefly exceed its base clock — leave it enabled, since a game server benefits from every extra MHz on its single core. <strong>C-states</strong> are deep idle power states the core drops into between packets; entering and exiting them adds latency exactly like the governor's ramp does. On a dedicated box tuned for lowest latency, admins often disable the deepest C-states (via a kernel boot parameter such as <code>processor.max_cstate=1</code> or the equivalent BIOS setting) so the core stays responsive. Do this only on bare metal you own and only if you have measured jitter that justifies it — it raises idle power and heat. The <code>performance</code> governor plus shallow C-states is the standard low-latency combination for a machine whose whole job is serving game frames.</p><h2>Common mistakes</h2><ul><li><strong>Leaving <code>ondemand</code> on a dedicated box</strong> — the ramp latency is exactly what hurts a bursty game server. Set <code>performance</code>.</li><li><strong>Setting it once, losing it on reboot</strong> — sysfs writes and <code>cpupower frequency-set</code> are not persistent. Bake it into boot.</li><li><strong>Expecting it to work on a VPS</strong> — if <code>scaling_governor</code> is absent, the host owns frequency. Chase steal instead.</li><li><strong>Judging by average CPU</strong> — low average does not mean low latency needs; a bursty server benefits from a pinned clock even at 20% average load.</li></ul><h2>Verification</h2><p>Confirm the change stuck and had an effect. Re-read <code>scaling_governor</code> for every core — all should say <code>performance</code>. Then watch the live clock under load with <code>watch -n1 "grep MHz /proc/cpuinfo"</code>; on <code>performance</code> the cores should sit at or near their maximum rated frequency constantly instead of bouncing between a low idle clock and boost. Finally, re-check your <a href="/tutorials/measure-server-fps">server FPS</a> stability — the average may not change, but the dips should shrink. Combine this with <a href="/tutorials/cpu-affinity-taskset-hlds">pinning the server to a core</a> so the same core is both dedicated and running flat-out.</p>
