Recommended Free Tools
Linux connects CPU frequency decisions to scheduler activity through CPUFreq governors such as schedutil. The scheduler supplies utilization signals; the governor uses them to request a performance level; and the active driver and hardware determine what can actually be delivered. A request is not a guarantee of sustained operating frequency.
How CPUFreq and the scheduler fit together
CPUFreq is a framework, not one universal frequency-control algorithm. Its core provides shared infrastructure and userspace interfaces, a scaling governor makes policy decisions, and a scaling driver translates those decisions into hardware-specific performance requests. The available behavior depends on the kernel build, platform, and active driver.
As an Amazon Associate I earn from qualifying purchases.
| Part | Role |
|---|---|
| CPUFreq core | Provides common infrastructure and userspace interfaces. |
| Scaling governor | Uses policy and workload information to choose a requested performance level. |
| Scaling driver | Converts governor decisions into requests understood by the hardware or platform. |
The Linux kernel documentation describes schedutil this way: “This governor uses CPU utilization data available from the CPU scheduler.” That connection lets the governor react to scheduler updates rather than relying only on a separate periodic estimate.
What schedutil reads from the scheduler
CFS utilization and PELT
For CFS-related callbacks, schedutil uses PELT utilization from the root control group. PELT tracks workload over time, including how much time tasks are running and how much they remain runnable. Under contention, a task may receive less running time even as runnable demand on the run queue grows. The scheduler’s signal therefore reflects more than a simple count of currently executing tasks.
#1 Best Overall
Frequency and CPU invariance
A raw utilization value does not represent the same compute capacity in every circumstance. A CPU running at a different frequency can complete work at a different rate, and different CPU types can have different capacities. Frequency and microarchitecture invariance adjust scheduler accounting to make utilization more comparable across those differences. This matters because schedutil bases its decision on that utilization signal.
How utilization becomes a frequency request
For frequency-invariant utilization, the documented schedutil relationship is:
f = 1.25 × f₀ × util / max
utilis the PELT utilization value.maxis the theoretical maximum of that utilization signal.f₀is the policy maximum frequency when utilization is frequency-invariant; otherwise it is the current frequency.
The factor of 1.25 provides headroom in the documented calculation; the result is still a requested operating point, not proof that the hardware will run there. Requests are constrained by the policy’s minimum and maximum and by the frequencies or performance states supported by the driver.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Why requests can change for scheduling class, I/O, and clamps
Real-time and deadline activity
When schedutil is called for real-time or deadline scheduling activity, it raises the request to the policy’s allowed maximum. This differs from the CFS path, which uses the root control group’s PELT utilization to compute a request.
I/O-wait boost
An I/O-wait boost can temporarily raise the request to the policy maximum. The request then backs down toward the value computed from utilization. A brief high request during I/O-related activity therefore need not indicate that sustained CPU demand is high.
Utilization clamping
Utilization clamping changes the utilization signal seen by schedutil and can consequently affect its frequency choice. It does not guarantee a universal performance improvement: the outcome depends on the configured clamps, workload, scheduler behavior, driver, and hardware.
Rank #4
Timing and driver-specific behavior
The schedutil tunable rate_limit_us sets the minimum interval between governor computations. The kernel documentation gives its default as 1.5 times the driver transition latency, or 1 ms when that latency is not provided. This is a computation interval, not a promise that hardware changes frequency at exactly that cadence.
Driver behavior also varies. For example, the AMD P-State documentation describes schedutil and ondemand as supported dynamic governors and documents an adjust_perf callback for performance updates similar to CPPC. Some drivers can use hardware information in their performance algorithms or bypass the generic governor layer. A system’s actual control path therefore cannot be inferred from the governor name alone.
Best Value
Why actual frequency may differ from the request
CPUFreq requests operate within policy and driver constraints, while the platform coordinates hardware behavior and enforces thermal and power limits. As the Linux kernel documentation puts it: “Though the intention may be to set an exact frequency for the policy, the actual frequency may vary depending on hardware coordination, thermal and power limits, and other factors.” Consequently, a requested value may not match a momentary reading or a sustained frequency under load.
What to check when diagnosing a system
Before comparing two machines or attributing a frequency change to schedutil, establish the active control path and constraints:
- Record the kernel version and identify the active CPUFreq driver and mode.
- Determine which governors are available and which one is active for the policy in question.
- Check the policy minimum and maximum and the performance range supported by the driver.
- Establish whether the utilization signal is frequency-invariant and account for CPU capacity differences.
- Identify whether the workload uses CFS, real-time, or deadline scheduling, and whether I/O-wait boosting or utilization clamps are relevant.
- Consider hardware coordination and thermal or power limits when observed frequency differs from a request.
These are kernel- and platform-dependent details. General CPUFreq documentation describes the framework, but does not establish the behavior of a particular distribution, processor, kernel configuration, or workload.
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.
