How to view the CPU frequency scaling policy in Linux

Monitoring CPU frequency scaling in Linux helps align system performance with power consumption targets on laptops, desktops, and servers. Observing how clock speeds ramp up or down under load provides insight into thermal throttling, power-saving states, and whether configured policies match workload expectations.

The kernel exposes CPU frequency scaling details through the cpufreq framework using the /sys/devices/system/cpu hierarchy. Files such as scaling_governor, scaling_cur_freq, scaling_min_freq, and scaling_max_freq describe the active governor, current frequency, and configurable bounds, while driver modules like acpi_cpufreq or intel_pstate implement the policy logic.

Available information depends on the active CPU driver and virtualization layer, so some systems may expose different files or fewer knobs than bare-metal hosts. Reading values from /sys is safe, but changing them without understanding the impact can force the CPU to run at inefficient frequencies or interfere with thermal limits, so the following commands focus only on viewing the current policy.

1. Open a terminal with a user account that can read /sys/devices/system/cpu.

   $ whoami
   user

2. Confirm that cpufreq-related drivers are loaded.

   $ lsmod | grep cpufreq
   acpi_cpufreq           20480  0
   intel_pstate           20480  0
   cpufreq_stats          16384  0

   Presence of modules such as acpi_cpufreq, intel_pstate, or cpufreq_stats indicates that CPU frequency scaling support is active.

3. List the cpufreq directories for each CPU core.

   $ ls /sys/devices/system/cpu/cpu*/cpufreq/
     /sys/devices/system/cpu/cpu0/cpufreq/
     /sys/devices/system/cpu/cpu1/cpufreq/
     /sys/devices/system/cpu/cpu2/cpufreq/
     /sys/devices/system/cpu/cpu3/cpufreq/

   Each directory under /sys/devices/system/cpu/cpuN/cpufreq contains files describing the policy and current frequency for core N.

4. View the active scaling governor for each CPU core.

   $ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
   ondemand
   ondemand
   ondemand
   ondemand

   The scaling_governor value shows the policy such as ondemand, performance, or powersave that controls how frequencies change.

5. Show the list of available governors supported by the driver for the first core.

   $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
   performance powersave ondemand conservative schedutil

   The scaling_available_governors line enumerates all governor modes that the current cpufreq driver can use on the CPU.

6. Check the current CPU frequency for all cores in kilohertz.

   $ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
   1500000
   1500000
   1500000
   1500000

   The scaling_cur_freq values change over time as load and policy decisions cause the CPU to throttle or boost.

7. Inspect the minimum and maximum frequency limits applied by the policy for each core.

   $ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq
   1200000
   1200000
   1200000
   1200000
   
   $ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq
   3000000
   3000000
   3000000
   3000000

   The scaling_min_freq and scaling_max_freq values define the allowed frequency range for the active governor and are shown in kilohertz.

8. Compare policy limits with hardware capabilities by viewing the hardware minimum and maximum for the first core.

   $ cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq
   800000
   $ cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
   3500000

   The cpuinfo_*_freq files describe the hardware range, which may be wider than the current policy range expressed by scaling_min_freq and scaling_max_freq.

9. Verify that frequency scaling reacts to load by observing current frequency values while running a workload.

   $ watch -n 1 'cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq'
   Every 1.0s: cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
   
   800000
   2200000
   2200000
   800000
   ##### snipped #####

   Rising values under load and lower values when idle confirm that the configured frequency scaling policy is active.