CPUFreq is the Linux kernel subsystem that coordinates CPU performance scaling. Its core provides the framework and userspace interface, governors decide what performance to request, and drivers translate requests into platform-specific hardware behavior. To inspect or change CPUFreq settings, start with the policy directory under /sys/devices/system/cpu/cpufreq/—but remember that a requested frequency is not necessarily the CPU’s instantaneous hardware clock.
What CPUFreq does
Linux CPUFreq mediates performance scaling: it provides common controls for requesting CPU performance changes while leaving the details of applying them to the active driver and hardware. The kernel documentation describes three main layers: the CPUFreq core, scaling governors, and scaling drivers. The Linux kernel’s CPU Performance Scaling documentation, authored by Rafael J. Wysocki, explains the subsystem and its interfaces.
As an Amazon Associate I earn from qualifying purchases.
- Core: supplies the shared framework and userspace interface, including policy objects and their sysfs attributes.
- Governor: estimates the CPU capacity needed and makes frequency requests according to an algorithm.
- Driver: exposes the platform’s scaling capabilities and communicates with its hardware using platform-specific mechanisms.
This model has an important exception: some drivers, including intel_pstate, can implement their own scaling algorithms rather than use the generic governor layer. Consequently, a governor name or setting should be interpreted in the context of the active driver, kernel configuration, and hardware.
How CPUFreq policies group CPUs
CPUFreq controls are associated with policy objects, not necessarily with one CPU apiece. A policy represents the CPUs that share a hardware performance-scaling interface. At initialization, the core creates policy directories in /sys/devices/system/cpu/cpufreq/, typically named policy0, policy1, and so on. A CPU’s own cpufreq link points to the policy associated with it.
#1 Best Overall
For example, inspect the policies and their CPU membership with:
ls -l /sys/devices/system/cpu/cpufreq/
cat /sys/devices/system/cpu/cpufreq/policy0/affected_cpus
cat /sys/devices/system/cpu/cpufreq/policy0/related_cpusReplace policy0 with a directory that exists on your machine. affected_cpus identifies CPUs currently affected by the policy; related_cpus identifies CPUs related to it by the scaling interface. Policy grouping depends on the platform, so do not assume each logical CPU has independent frequency controls.
How to check the active driver, governor, and limits
Common policy attributes include the driver, selected governor or driver algorithm, and minimum and maximum frequency limits. The exact files available depend on driver support and kernel configuration.
Free tools Windows power users keep installed
One-click scans. No signup required.
- Find a policy: run
ls /sys/devices/system/cpu/cpufreq/and choose an existingpolicyXdirectory. - Check the driver and governor: run
cat /sys/devices/system/cpu/cpufreq/policyX/scaling_driverandcat /sys/devices/system/cpu/cpufreq/policyX/scaling_governor. - Check available governors: if present, read
scaling_available_governors. The options are not universal; modules may need to be loaded, and some drivers provide their own algorithms. - Inspect policy limits: read
scaling_min_freqandscaling_max_freq. CPUFreq expresses these values in kHz. The minimum must not exceed the maximum.
Use the same directory in each command, substituting the policy name found on your system. Some platforms also expose bios_limit, a firmware-reported upper limit; the kernel documentation notes that this attribute does not account for ACPI thermal limitations. Driver-specific files may appear as well.
What the common governors request
Generic governor names describe request behavior, not a guarantee that the hardware will hold a particular clock. The active driver and policy limits shape what each request means.
| Governor | Request behavior | Important qualification |
|---|---|---|
performance |
Requests the highest frequency permitted by the policy’s maximum limit. | It is not an unconditional hardware override; platform constraints still matter. |
powersave |
Requests the lowest frequency permitted by the policy’s minimum limit. | It does not guarantee a fixed instantaneous hardware clock. |
userspace |
Allows userspace to request a frequency through scaling_setspeed. |
The actual hardware frequency can differ because of coordination, thermal limits, or power limits. |
schedutil |
Uses CPU scheduler utilization data to determine frequency requests. | For real-time or deadline scheduling classes, the kernel documentation says it raises frequency to the allowed maximum. |
These generic governors may not all be available on a particular system. A driver such as intel_pstate can expose driver-provided scaling algorithms through the relevant interface instead of relying on the generic governor layer.
Rank #3
How to change the governor
Changing a sysfs attribute requires write permission, commonly obtained through root privileges. First verify that the desired option appears in the policy’s available-governor list. Then write it to that policy’s scaling_governor attribute:
cat /sys/devices/system/cpu/cpufreq/policyX/scaling_available_governors
sudo sh -c 'echo schedutil > /sys/devices/system/cpu/cpufreq/policyX/scaling_governor'
cat /sys/devices/system/cpu/cpufreq/policyX/scaling_governorReplace schedutil with an option actually reported by your policy, and replace policyX with its real directory name. The final command checks the selected value. If the write fails, the option may be unavailable, the file may be read-only, or the active driver may use a different control model. A successful write changes the runtime setting; whether it persists after reboot depends on how the system configures CPUFreq.
Why scaling_cur_freq may not match the CPU clock
scaling_cur_freq commonly reports the last frequency requested through the scaling interface. It is not necessarily a direct measurement of the instantaneous frequency at which the hardware is running. Some architectures can report a more precise value through this attribute, but the kernel documentation still cautions that it may not equal the exact instantaneous hardware frequency.
If available, cpuinfo_cur_freq is defined as the current frequency obtained from hardware. Availability and measurement behavior depend on the platform. Check both files, if present, and treat each according to what it represents rather than assuming one universally reliable clock reading:
cat /sys/devices/system/cpu/cpufreq/policyX/scaling_cur_freq
cat /sys/devices/system/cpu/cpufreq/policyX/cpuinfo_cur_freqDifferent readings or a gap between a request and observed operation can reflect the distinction between a software request and hardware behavior. Thermal, power, firmware, and hardware constraints can also bound the result.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Why performance and power change together
Frequency scaling is a performance-and-power tradeoff, not a promise that increasing frequency will yield a fixed amount of extra work. The kernel documentation notes that higher frequency and voltage can let a CPU retire more instructions per unit time, while also increasing energy use per unit time or power draw. The actual effect varies by processor, workload, and platform conditions.
Best Value
What to compare when diagnosing two systems
To explain why two Linux machines expose different controls or behave differently, compare the factors that determine the interface and its meaning:
- Active CPUFreq scaling driver and whether it uses generic governors or its own algorithms.
- Available governors or driver-provided algorithms on the target kernel.
- Which CPUs share each policy.
- Supported policy minimum and maximum frequency limits.
- Whether a displayed frequency is a scaling request or a hardware-derived reading.
- Firmware, thermal, and power constraints that may limit operation.
There is no universal ranking that makes one governor fastest or most power-efficient on every combination of hardware and workload. The meaningful comparison is what each system’s driver, policies, measurements, and constraints actually expose.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
