Understanding CPU Frequency Scaling (cpufreq) in Linux: Architecture, Governors, and Interactive/Schedutil

When buying a smartphone, users often look at the CPU core count (e.g., 8‑core vs 4‑core) and the maximum CPU frequency, which are basic hardware parameters that affect performance.

The evolution of mobile processors has moved from single‑core designs to multi‑core and now to big‑LITTLE (heterogeneous) architectures. CPU frequencies have progressed from tens of MHz to several GHz.

Modern smartphones typically use a big‑LITTLE configuration: low‑power cores (Power Core) handle light workloads such as e‑book reading or web browsing, while high‑performance cores (Performance Core) handle demanding tasks like gaming or camera processing.

Why does the CPU need dynamic frequency scaling? Dynamic Clock and Voltage Scaling (DCVS) adjusts frequency and voltage to meet performance requirements while minimizing power consumption. Running the CPU at the highest frequency all the time would waste battery life, especially on battery‑constrained devices.

The Linux cpufreq framework is organized into three layers:

1) Framework layer : Provides generic functions (e.g., cpufreq.c, cpufreq_stats.c) and exposes a sysfs interface under /sys/devices/system/cpu for querying and controlling CPU frequency policies.

2) Driver layer : Supplies hardware‑specific drivers that implement frequency control for a given CPU. Drivers register via cpufreq_register_driver . For example, Qualcomm platforms register their driver in qcom-cpufreq-hw.c .

3) Core (governor) layer : Implements the algorithms that decide which frequency to select. Governors register with cpufreq_register_governor and are exposed through sysfs files such as scaling_available_governor and scaling_governor .

The central data structure is struct cpufreq_policy , which represents the frequency policy for a CPU or a cluster of CPUs that share the same clock source.

Typical governors include:

Interactive governor : Designed for Android devices, it samples CPU utilization periodically and introduces concepts such as hi_speed (jump to a high frequency when utilization exceeds go_hispeed_load ), target_loads (per‑frequency utilization thresholds), above_hispeed_delay (minimum residence time before scaling higher), and boost/pulse mechanisms for short‑term performance spikes.

Schedutil governor : Uses scheduler events instead of periodic sampling. When a task is woken up and added to a CPU runqueue, the scheduler calls cpufreq_update_util to raise the frequency; when a task sleeps, the frequency is lowered. This event‑driven approach reduces latency and overhead, especially on high‑refresh‑rate displays (90 Hz, 120 Hz).

The article concludes that the Linux cpufreq framework provides a flexible stack—from hardware drivers up to high‑level governors—allowing fine‑grained control of CPU performance and power consumption. The analysis is based on the OPPO open‑source kernel 4.19 (https://github.com/oppo-source/kernel_msm-4.19) and references several kernel and Qualcomm documents.