P-states and C-states: what your CPU does when it’s idle

December 31, 2025 • February 3, 2026 • Read: 22 min • Views: 0

Was this helpful?

The incident report always starts the same way: “CPU was only at 12% and latency spiked anyway.”
You look at dashboards, see plenty of headroom, and then somebody suggests “maybe the database is slow.”
Meanwhile, the real villain is quieter: the CPU is saving power so aggressively that waking it up costs you milliseconds you didn’t budget.

P-states and C-states are the knobs and gears behind “idle.” They’re also why a server can be “mostly idle”
and still feel like it’s walking through molasses when the next burst of work arrives. If you run production systems,
you don’t have to become a CPU microarchitect—but you do need enough operational literacy to avoid stepping on the landmines.

A production-grade mental model: P-states vs C-states

Think of your CPU as having two kinds of “modes”:

P-states (Performance states): the CPU is running, but at different frequency/voltage points.
Higher P-state performance generally means higher frequency and higher power. Lower P-state performance means slower but cheaper.
C-states (Idle states): the CPU is not running useful instructions.
The deeper the C-state, the more of the core (and sometimes the whole package) can be powered down, saving more energy—but waking up takes longer.

That’s the simple version. The operational version adds two footnotes you should tattoo onto your runbooks:

P-states are not a “set and forget” knob. The OS, firmware, and the CPU itself can all influence frequency selection.
In modern Intel systems, hardware can do a lot of the decision-making even if you think Linux is in charge.
C-states can be per-core and per-package. A single noisy neighbor core can keep the whole socket from reaching deep package sleep.
Conversely, a “quiet” system can get so deep into sleep that your next request pays an ugly wake-up penalty.

One more mental shortcut: P-states are about “how fast while working.” C-states are about “how asleep while waiting.”
Most incidents happen when you optimize one and forget the other.

What the CPU actually does when “idle”

When Linux has nothing runnable for a CPU, it executes an idle loop. The idle loop isn’t just spinning
(unless you force it to). It typically issues an instruction like HLT (halt) or uses more advanced
mechanisms that let the CPU enter deeper sleep states.

Core C-states: C0 through “deep enough to annoy you”

C0 means “active.” Everything else is some flavor of “not executing instructions.” The exact mapping differs across vendors,
but the operational pattern is consistent:

C1: light sleep. Quick to exit. Minimal power savings.
C1E: enhanced C1; often reduces voltage more aggressively.
C3: deeper sleep; more internal clocks gated; higher exit latency.
C6/C7 and friends: very deep sleep; can flush caches, power down parts of the core; exit latency can become measurable.

Exit latency is the hidden tax. If your workload is bursty and latency sensitive, deep C-states can turn
“mostly idle” into “periodically slow.”

Package C-states: the whole socket goes napping

Package C-states (often labeled PC2/PC3/PC6/PC10) are where the big power savings live.
They’re also where surprises live. The package can only go deep if conditions are met:

All cores are idle enough.
Uncore components (LLC, memory controller, interconnect) can be clock/power gated.
Devices and firmware agree it’s safe.

In server environments, a single chatty interrupt source, timer tick, or misconfigured power policy can block deep package states.
Or the opposite: deep package sleep is allowed, and your tail latency starts doing interpretive dance.

P-states: frequency selection is not a single knob anymore

The old story was: OS selects a frequency from a table; CPU runs it. The modern story is: the OS sets policies and hints,
and the CPU’s internal logic often does the fast control loops. Intel’s intel_pstate driver, AMD’s CPPC,
and hardware-managed P-states blur the line between “governor” and “firmware.”

Turbo complicates things further. Turbo isn’t “a frequency.” It’s a set of opportunistic boost behaviors
limited by power, temperature, current, and how many cores are active. Your monitoring may say “3.5 GHz”
while the CPU is doing per-core boosts that vary microsecond to microsecond.

Joke #1: If you ever want to feel powerless, try arguing with a CPU about what “maximum frequency” means.

Why you should care: latency, jitter, throughput, and bills

Latency and tail latency

Deep C-states add wake-up latency. Frequency scaling adds ramp-up latency. Usually this is microseconds to low milliseconds,
which sounds small until you’re running:

RPC services with tight SLOs (p99 matters, not average)
storage backends where IO completion time is user-visible
databases with lock contention where small delays magnify
low-latency trading systems where jitter is a career risk

In other words: if your system is “idle most of the time” but must respond fast when it isn’t idle, you have to care.

Throughput and sustained performance

P-states and turbo decide how much work you do per watt. But turbo is bounded by power limits (PL1/PL2 on Intel),
thermals, and platform constraints. If you force “performance mode” everywhere, you might win short benchmarks and lose sustained throughput
because you hit power/thermal ceilings and throttle hard.

Power, cooling, and real money

If you operate at scale, CPU power policy changes the data center’s story: electricity, cooling, and rack density.
Even if you don’t pay the power bill directly, you’ll pay it in capacity planning.

Here’s the cynical SRE truth: you can’t spend your way out of latency jitter if your fleet configuration is inconsistent.
And you can’t tune your way out of a power budget if your application spins doing nothing.

Interesting facts and short history (because this mess has roots)

ACPI standardized power states so operating systems could manage power across hardware vendors instead of bespoke BIOS interfaces.
Early “SpeedStep” era CPUs made frequency scaling mainstream; before that, “power management” was mostly “turn the screen off.”
Modern turbo behavior is power-limited, not frequency-limited: CPUs chase power and thermal envelopes, not a fixed clock.
C-states predate cloud, but cloud made their tradeoffs painful: multi-tenant workloads are bursty and unpredictable.
Tickless kernels (NO_HZ) reduced periodic timer interrupts so CPUs could stay idle longer and reach deeper C-states.
Intel introduced hardware-managed P-state control to react faster than an OS scheduler loop could.
RAPL (Running Average Power Limit) gave software a way to measure/limit CPU energy, making power a first-class metric.
Package C-states became a big deal as “uncore” power (LLC, memory controller, interconnect) started rivaling core power.
Virtualization complicated everything: a guest’s “idle” isn’t necessarily host idle; halting in a VM involves hypervisor policy.

How Linux controls P-states and C-states

The control plane: drivers, governors, and policies

On Linux, CPU frequency scaling is usually managed by the cpufreq subsystem. Two common drivers you’ll see:

intel_pstate (Intel): often the default on modern Intel. Can do “active” mode where the CPU participates heavily in decisions.
acpi-cpufreq: more traditional ACPI-based driver with explicit frequency tables.

Governors are policies like performance, powersave, and (depending on driver) schedutil.
Don’t treat governor names as universal truths; their behavior can differ by driver.

The idle plane: cpuidle, C-state drivers, and latency constraints

C-states in Linux are managed by the cpuidle subsystem. It picks an idle state based on:

predicted idle duration (how long until the next event wakes the CPU)
exit latency of each idle state
QoS constraints (latency sensitivity hints from the kernel/userspace)
what the platform and firmware allow

BIOS/UEFI: the place where “we’ll just change one setting” becomes folklore

Firmware settings can override or constrain everything:

Maximum allowed C-state (e.g., limit to C1)
Package C-state limits
Turbo enable/disable
Energy/Performance Bias (Intel’s EPB)
Vendor “power profiles” that do multiple things at once

In production, the most common failure mode is not “wrong kernel.” It’s “different BIOS defaults across batches.”

One reliability quote (paraphrased idea)

Paraphrased idea attributed to John Ousterhout: complexity is the root cause of many reliability problems.
Power management is complexity with a watt meter.

Practical tasks: commands, output meaning, and decisions

The only tuning that matters is the tuning you can verify. Below are real tasks I expect an on-call engineer to execute,
with commands, example outputs, and what decision you make from them.

Task 1: Identify the active CPU frequency driver and governors

cr0x@server:~$ cpupower frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  available cpufreq governors: performance powersave
  current policy: frequency should be within 800 MHz and 3900 MHz.
                  The governor "powersave" may decide which speed to use
  current CPU frequency: 1200 MHz (asserted by call to hardware)
  boost state support:
    Supported: yes
    Active: yes

What it means: You’re on intel_pstate; governor choices are limited and behavior is driver-specific.
Current frequency is low because policy allows it. Turbo is enabled.

Decision: If you’re diagnosing latency spikes, note that powersave under intel_pstate can still boost,
but ramp characteristics differ. Don’t switch governors blindly; measure first.

Task 2: Check min/max frequency policy per CPU

cr0x@server:~$ for f in /sys/devices/system/cpu/cpu*/cpufreq/scaling_{min,max}_freq; do echo "$f: $(cat $f)"; done | head
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq: 800000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq: 3900000
/sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq: 800000
/sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq: 3900000

What it means: The OS policy bounds are wide open. If performance is still poor, the limitation is elsewhere
(power caps, thermals, C-states, contention).

Decision: If scaling_max_freq is unexpectedly low, suspect a tuning profile, container runtime constraints,
or platform power limit events.

Task 3: Inspect turbo/boost status

cr0x@server:~$ cat /sys/devices/system/cpu/cpufreq/boost
1

What it means: Turbo/boost is enabled.

Decision: For latency-sensitive services, turbo often helps (faster service time).
For deterministic latency, turbo can add thermal variability; consider locking policy only after measurement.

Task 4: Verify CPU idle state availability and residency (core C-states)

cr0x@server:~$ sudo cpupower idle-info
CPUidle driver: intel_idle
CPUidle governor: menu
analyzing CPU 0:
  Number of idle states: 4
  Available idle states: POLL C1 C1E C6
  C1: exit latency 2 us
  C1E: exit latency 10 us
  C6: exit latency 85 us

What it means: Deep C6 exists with ~85 µs exit latency (example). That’s not catastrophic, but it’s not free.

Decision: If your p99 spikes correlate with idle periods, consider limiting deepest C-state only on affected nodes and re-test.

Task 5: Check per-state time and usage counts for idle states

cr0x@server:~$ for s in /sys/devices/system/cpu/cpu0/cpuidle/state*; do \
  echo "$(basename $s) name=$(cat $s/name) disable=$(cat $s/disable) time=$(cat $s/time) usage=$(cat $s/usage)"; \
done
state0 name=POLL disable=0 time=122 usage=18
state1 name=C1 disable=0 time=983421 usage=24011
state2 name=C1E disable=0 time=221934 usage=9120
state3 name=C6 disable=0 time=55290321 usage=110432

What it means: CPU0 spends a lot of time in C6. That’s good for power. It can be bad for wake latency.

Decision: If you’re seeing tail latency, this is your smoking gun candidate. Next, correlate with application latency metrics and interrupts.

Task 6: Check package C-state residency (Intel, via turbostat)

cr0x@server:~$ sudo turbostat --Summary --quiet --show PkgWatt,PkgTmp,Pkg%pc2,Pkg%pc6,Pkg%pc10 --interval 1 --num_iterations 3
PkgWatt  PkgTmp  Pkg%pc2  Pkg%pc6  Pkg%pc10
  32.15     54      2.12     8.41     61.77
  28.02     52      1.88     7.96     68.10
  35.44     55      2.30     9.02     58.33

What it means: The package is frequently reaching PC10 (deep sleep). Power is low. Great for efficiency.
Also a classic cause of “cold-start latency” on wake.

Decision: If you run low-latency workloads, consider limiting package C-states or using a low-latency tuned profile on those nodes.
If you run batch jobs, celebrate and move on.

Task 7: Look for power limit and throttling signals (Intel RAPL / thermal)

cr0x@server:~$ sudo turbostat --quiet --show Bzy_MHz,Avg_MHz,Busy%,CoreTmp,PkgTmp,PkgWatt,CorWatt,GFXWatt --interval 1 --num_iterations 2
Bzy_MHz  Avg_MHz  Busy%  CoreTmp  PkgTmp  PkgWatt  CorWatt  GFXWatt
   4200     1850  22.15       72      79    165.2     92.1     0.0
   4100     1902  23.40       74      81    165.0     93.0     0.0

What it means: Boost clocks exist, but package power is high. If temps climb, you may throttle soon.

Decision: If performance is inconsistent under load, inspect cooling, power limits, and sustained turbo behavior before blaming the kernel.

Task 8: Confirm kernel tick mode and timer behavior (idle disruption)

cr0x@server:~$ grep -E 'NO_HZ|CONFIG_HZ' -n /boot/config-$(uname -r) | head -n 5
114:CONFIG_HZ=250
501:CONFIG_NO_HZ_COMMON=y
504:CONFIG_NO_HZ_IDLE=y
507:CONFIG_NO_HZ_FULL is not set

What it means: Tickless idle is enabled (NO_HZ_IDLE), which helps deep C-states. Not full tickless.

Decision: If your workload needs consistent low latency, you may prefer fewer deep idle transitions (policy), not necessarily changing kernel config.

Task 9: Identify interrupt hotspots that prevent idle or cause wake storms

cr0x@server:~$ sudo cat /proc/interrupts | head -n 15
           CPU0       CPU1       CPU2       CPU3
  0:         21         18         19         22   IO-APIC   2-edge      timer
  1:          0          0          0          0   IO-APIC   1-edge      i8042
 24:     883421     102331      99321      90122   PCI-MSI  327680-edge  eth0-TxRx-0
 25:     112331     843221     121112     110998   PCI-MSI  327681-edge  eth0-TxRx-1

What it means: NIC queues are heavy on certain CPUs. This can keep cores from idling and can also cause bursty wakeups.

Decision: Consider IRQ affinity tuning (or irqbalance behavior) if you see single-core hotspots or latency spikes aligned to interrupts.

Task 10: Check irqbalance status and whether it’s fighting your pinning

cr0x@server:~$ systemctl status irqbalance --no-pager
● irqbalance.service - irqbalance daemon
     Loaded: loaded (/lib/systemd/system/irqbalance.service; enabled; preset: enabled)
     Active: active (running) since Tue 2026-01-10 08:21:10 UTC; 2h 12min ago
       Docs: man:irqbalance(1)
   Main PID: 912 (irqbalance)

What it means: irqbalance is active. Good default—unless you do manual IRQ pinning for low-latency and forgot to disable it.

Decision: If you need strict CPU isolation, either configure irqbalance banned CPUs or disable it and manage affinities explicitly.

Task 11: See if a tuning profile is enforcing aggressive power savings

cr0x@server:~$ tuned-adm active
Current active profile: virtual-guest

What it means: A tuned profile is active, potentially altering CPU governor and other latency-relevant knobs.

Decision: For a database host or latency-sensitive RPC service, test latency-performance (or vendor-recommended profile) on a canary node.

Task 12: Verify current governor quickly across all CPUs

cr0x@server:~$ grep -H . /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor 2>/dev/null | head
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:powersave
/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor:powersave
/sys/devices/system/cpu/cpu2/cpufreq/scaling_governor:powersave
/sys/devices/system/cpu/cpu3/cpufreq/scaling_governor:powersave

What it means: All CPUs are on powersave.

Decision: If you’re chasing latency regressions, switch a single host to performance temporarily and measure p99. Don’t roll fleet-wide based on vibes.

Task 13: Temporarily change governor (and understand what you’re risking)

cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3

What it means: You requested the performance governor. On intel_pstate, this changes policy behavior, not a fixed clock.

Decision: Use this as a controlled experiment. If latency improves materially and power budget allows, consider a tuned profile rather than ad-hoc changes.

Task 14: Limit deepest C-state (surgical test, not a lifestyle)

cr0x@server:~$ echo 1 | sudo tee /sys/devices/system/cpu/cpu0/cpuidle/state3/disable
1

What it means: You disabled one idle state (here, state3 might be C6). This forces shallower sleep on CPU0.

Decision: If p99 improves and power draw rises acceptably, apply via a persistent method (kernel args, tuned, or systemd unit) and document it.

Task 15: Check for virtualization effects: are you tuning the guest while the host decides?

cr0x@server:~$ systemd-detect-virt
kvm

What it means: You’re inside a VM. Guest power knobs may have limited effect; host policy and hypervisor scheduling matter more.

Decision: If you need low-latency behavior, work with the platform team: CPU pinning, host governor, and C-state policy are the real levers.

Task 16: Check CPU pressure and scheduling contention (because “idle” can be a lie)

cr0x@server:~$ cat /proc/pressure/cpu
some avg10=0.00 avg60=0.10 avg300=0.08 total=18873412
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

What it means: CPU pressure is low; the scheduler isn’t struggling. If latency is bad, focus on wake/sleep behavior, interrupts, IO, or lock contention.

Decision: If some or full is high, don’t chase C-states first—fix contention, CPU limits, or noisy neighbors.

Fast diagnosis playbook

This is the order I use when someone says “latency spikes when the box is mostly idle” or “CPU is low but things are slow.”
It’s optimized for finding the bottleneck quickly, not for making you feel clever.

First: decide if you’re chasing CPU power behavior or something else

Check CPU pressure (scheduler contention):
if PSI is high, you’re not “idle,” you’re oversubscribed or throttled.
Check run queue and steal time (especially in VMs):
low utilization can coexist with high latency if you’re waiting to be scheduled.
Check iowait and storage latency:
lots of “idle CPU” is actually “blocked on IO.”

Second: confirm what power policy is active

Driver + governor via cpupower frequency-info.
Turbo enabled? via /sys/devices/system/cpu/cpufreq/boost.
Tuned profile or vendor service enforcing policy.

Third: measure C-state residency and wake-related disruption

Core C-state usage/time via /sys/.../cpuidle or cpupower idle-info.
Package C-states via turbostat (if available).
Interrupt hotspots via /proc/interrupts and IRQ affinity tools.

Make one change at a time, on one node, with a timer

The fastest way to waste a week is to toggle BIOS settings, kernel parameters, and tuned profiles in the same maintenance window.
Change one thing, measure p95/p99 and power/thermals, then decide.

Three corporate-world mini-stories from the trenches

Mini-story 1: The incident caused by a wrong assumption

A team rolled out a new “lightweight” internal API gateway. It was efficient: low CPU, short bursts, heavy on network interrupts.
On dashboards, CPU utilization hovered around 15–25%. Everyone congratulated themselves for not overprovisioning.
Then the p99 latency doubled during off-peak hours, exactly when traffic got quieter.

The first assumption was classic: “less load means more headroom.” But the service was bursty.
During quiet periods, the CPUs entered deep package C-states. When the next burst arrived, request handling paid wake-up latency
plus frequency ramp latency. Individually small, collectively ugly.

The second assumption: “We’re on performance governor, so frequency is high.” They weren’t.
Half the fleet had a different BIOS power profile. Those hosts allowed deeper package states and had a more energy-biased policy.
The fleet was heterogeneous, and the load balancer happily mixed hosts with different wake behaviors.

The fix wasn’t heroic. They standardized firmware profiles, then canaried a tuned low-latency profile on gateway nodes only.
They kept deep sleep enabled for batch workers. Latency stabilized, power stayed sane, and the incident ended not with a postmortem novel,
but with a short checklist added to provisioning.

Mini-story 2: The optimization that backfired

A storage team (think: distributed block service) wanted to cut power usage. They forced deeper C-states and set governors to powersave across
storage nodes. On paper it was responsible: storage nodes were “mostly waiting on IO,” and CPUs didn’t look busy.

What they missed was how storage behaves under mixed workloads. IO completion paths are latency-sensitive and interrupt-driven.
The service would sit quiet, then suddenly process a storm of completions, checksum work, and network replies.
With deep C-states, the interrupt-to-handler latency grew. With aggressive frequency scaling, the cores started slow, then ramped.

The backfire showed up as a strange symptom: average latency stayed okay, but tail latency and jitter became brutal.
Clients retried. Retries caused microbursts. Microbursts made the CPUs bounce between sleep and wake even more.
The “power-saving” change created a feedback loop that wasted both power and time.

They rolled back on the storage frontends but kept power savings on background compaction nodes.
The real lesson was scope: power policy is workload-specific. Apply it per role, not per cluster, and always watch p99 and retry rates.

Mini-story 3: The boring but correct practice that saved the day

Another company ran a Kubernetes fleet with mixed instance generations. Their platform team did something profoundly unsexy:
they maintained a hardware capability matrix and a provisioning test that recorded C-state availability, turbo status, and idle residency.
Every new BIOS update had to pass the same tests before being allowed into the golden image pipeline.

One quarter, a vendor firmware update changed default package C-state limits.
Nothing exploded immediately. That’s the trick—this kind of change doesn’t always break things loudly. It just alters latency characteristics.

Their tests caught it because the recorded package C-state residency changed significantly on idle nodes.
They didn’t need a customer to complain first. They paused the rollout, adjusted the firmware policy, and documented the difference.

The result was boring: no incident. The platform team got no praise.
But the application teams never had to learn about package C-states at 3 a.m., which is the highest form of operational success.

Joke #2: The best power-management change is the one that never makes it into a postmortem slide deck.

Common mistakes (symptoms → root cause → fix)

1) “CPU is low but p99 latency is high”

Symptoms: low average CPU utilization; big tail latency spikes during quiet periods; better latency under sustained load.

Root cause: deep C-states and/or aggressive frequency scaling cause wake and ramp penalties; bursty traffic triggers repeated transitions.

Fix: measure C-state residency (core and package). Canary a low-latency profile or limit deepest C-states on affected nodes.
Confirm BIOS power profile consistency across fleet.

2) “Frequency stuck low even under load”

Symptoms: cpupower frequency-info shows low current frequency; throughput below expectations; CPU temps moderate.

Root cause: scaling max frequency capped by policy, container CPU quota interactions, or platform power limit constraints.

Fix: check scaling_max_freq and tuned profile; confirm turbo; inspect power limits/throttling via turbostat.
In containers, verify CPU quota and cpuset assignments.

3) “Performance improved on one node but not another”

Symptoms: same software, different latency; tuning changes work inconsistently across hosts.

Root cause: heterogeneous firmware defaults, microcode differences, or different frequency drivers (intel_pstate vs acpi-cpufreq).

Fix: standardize BIOS settings; ensure consistent kernel parameters; inventory driver selection and microcode versions.

4) “IRQ storms prevent idle and waste power”

Symptoms: package never reaches deep C-states; higher idle watts; certain CPUs show huge interrupt counts.

Root cause: interrupt affinity imbalance, misconfigured NIC queues, chatty devices, or timer behavior.

Fix: inspect /proc/interrupts; tune IRQ affinity; configure queue counts appropriately; check irqbalance configuration.

5) “Disabled C-states and now throughput got worse”

Symptoms: power draw increased; thermal throttling appears; sustained performance drops after a short initial boost.

Root cause: removing idle savings raises baseline temperature/power, reducing turbo headroom and causing throttling.

Fix: don’t blanket-disable deep states. Use per-role policies. Monitor thermals and package power; aim for stability, not maximum clocks.

6) “We pinned CPUs, but latency still jitters”

Symptoms: CPU isolation configured; still see jitter; occasional long tails.

Root cause: power management still transitions cores/package; interrupts land on isolated CPUs; hyperthread sibling contention.

Fix: align IRQ affinity with isolation; consider limiting deep C-states for isolated cores; check SMT policy for latency-critical workloads.

Checklists / step-by-step plan

Checklist A: Standardize a fleet power baseline (the boring part that prevents surprises)

Inventory CPU models, microcode versions, and virtualization status across nodes.
Record frequency driver (intel_pstate/acpi-cpufreq) and governors in configuration management.
Record BIOS/UEFI power profile settings (C-state limits, turbo, EPB) per hardware generation.
Define role-based policies: latency-critical, balanced, batch/efficiency.
Enforce tuned profiles or equivalent via automation; no hand-tuned snowflakes.
Continuously sample package C-state residency and watts on idle canaries to detect drift after firmware updates.

Checklist B: Tune a latency-sensitive service node (safely)

Baseline: capture p95/p99 latency, error/retry rate, and power draw at idle and under typical burst.
Confirm it’s not CPU contention: check PSI CPU and run queues.
Measure package C-state residency on idle and during bursts.
Canary change: switch tuned profile or governor on one node.
If still spiky, test limiting deepest C-state (temporary) and re-measure.
Validate thermals and sustained power limits; watch for throttling.
Roll out per role, not per fleet. Document the policy with “why,” not just “what.”

Checklist C: Tune an efficiency-first batch worker node

Confirm workload is throughput-oriented and tolerant to jitter.
Enable/allow deep package C-states and balanced governors.
Watch for interrupt storms that keep the package awake (wasted watts).
Monitor energy per job (or per GB processed), not just runtime.

FAQ

1) Are P-states and C-states independent?

Mostly, but not entirely. C-states govern what happens when idle; P-states govern active performance.
In practice they interact through thermals and power limits: deeper idle can improve turbo headroom, and disabling idle can reduce sustained boost.

2) Should I always use the `performance` governor on servers?

No. For latency-critical frontends, it can help. For batch fleets, it’s often wasteful.
Also, on intel_pstate, performance doesn’t mean “fixed max clock.” It means a more aggressive policy.
Make role-based decisions and measure p99 and watts.

3) If C-states add latency, why not disable them everywhere?

Because you’ll pay in power, heat, and sometimes throttling—plus reduced turbo headroom.
Disabling deep C-states can be a targeted tool for specific roles. It’s rarely a good default for an entire fleet.

4) Why does latency get better under steady load?

Under steady load, cores stay in C0 and frequencies stabilize at higher levels. You avoid wake-up and ramp-up costs.
Bursty loads repeatedly pay those costs, and tail latency suffers.

5) How do I know whether the OS or hardware is controlling frequency?

Start with cpupower frequency-info to see the driver. On modern Intel, intel_pstate in active mode means hardware plays a big role.
Also look at whether the current frequency is “asserted by call to hardware” in the output.

6) Does virtualization change the story?

Yes. A guest’s idle state is mediated by the hypervisor. Frequency and deep package sleep are typically host-controlled.
If you’re tuning inside a VM and not seeing results, it’s not because you’re unlucky; it’s because you’re not holding the right levers.

7) What’s the difference between core C-states and package C-states operationally?

Core C-states affect a single core’s sleep depth and wake latency. Package states affect the socket-level components and can save much more power.
Package states can also have more noticeable “first request after idle” penalties, depending on platform.

8) Can interrupt tuning fix C-state-related latency?

Sometimes. If interrupts are waking idle cores constantly, you’ll see power waste and jitter.
If interrupts are concentrated on a few CPUs, those CPUs may never sleep while others go deep, creating uneven response behavior.
Balancing or pinning interrupts correctly can stabilize latency.

9) How do I decide between “low latency” and “energy efficient” modes?

Use the workload’s SLO and cost model. If you have strict p99 targets and bursty traffic, bias toward low latency on those nodes.
If you have batch jobs or elastic queues, bias toward efficiency. Avoid mixing policies in the same pool behind one load balancer.

10) What’s a safe first experiment if I suspect C-states?

Canary a single node: capture baseline, then switch to a low-latency tuned profile or limit the deepest idle state temporarily.
If p99 improves without triggering throttling or unacceptable power increase, you’ve proven causality.

Conclusion: practical next steps

“Idle” is not a neutral state. It’s an active policy decision made by layers of silicon, firmware, and kernel code—each trying to save power,
occasionally stealing your latency budget in the process.

Next steps that actually hold up in production:

Measure before tuning: collect governor/driver, C-state residency, and p95/p99 latency on a canary node.
Standardize firmware policy: inconsistent BIOS defaults are a silent fleet killer.
Split by role: low-latency nodes and efficiency nodes should not share the same power policy.
Make changes reversible: toggles via tuned profiles or config management, not artisanal SSH sessions.
Watch tail latency and retries: averages will lie to you with a straight face.