In‑Depth Analysis of the Linux Schedutil Governor (sugov)

This article provides a detailed, code‑level analysis of the Linux schedutil governor (referred to as sugov ) used for CPU frequency scaling. It is organized into four main parts: an overview of the sugov software structure, the data structures it uses, the interaction between sugov and the cpufreq core, and the governor’s frequency‑adjustment logic.

1. Overview of sugov – Sugov is a kernel governor that adjusts CPU frequency based on the current CPU utilization. It registers callback functions ( sugov_update_shared / sugov_update_single ) with the scheduler’s load‑tracking module, which are invoked whenever CPU utilization changes. The governor can be tuned via parameters exposed to userspace, allowing different performance/power trade‑offs for various scenarios.

2. Data structures – Three key structures are described: struct sugov_tunables – holds tunable parameters for the governor; struct sugov_cpu – per‑CPU data used to store frequency‑scaling information; struct sugov_policy – per‑cluster data that aggregates per‑CPU information. The article includes schematic diagrams of these structures.

3. Registration and initialization – To become a cpufreq governor, sugov defines a struct cpufreq_governor object and registers it via cpufreq_governor_init(schedutil_gov) . After registration, the governor becomes active only when the user selects it through /sys/devices/system/cpu/cpufreq/policyX/scaling_governor . The initialization process involves allocating policy objects, linking them with the cpufreq framework, allocating tunables, and optionally enabling fast‑switch support. Fast‑switch allows frequency changes without blocking, but it is mutually exclusive with the traditional cpufreq transition notifier.

4. Frequency‑adjustment workflow – When the scheduler reports a change in CPU utilization, cpufreq_update_util notifies sugov. Sugov then computes the maximum utilization across all CPUs in a cluster, maps this utility to a target frequency using the formula:

next_freq = C * max_freq * util / max

where C = 1.25 provides a 20 % headroom. The target frequency is then rounded to the nearest supported hardware frequency. The governor respects a minimum frequency‑update interval (rate limit) to avoid excessive scaling, but the limit can be bypassed when policy limits change or when deadline‑type tasks trigger a boost.

5. I/O wait boost – To improve throughput under light load, sugov implements an iowait‑boost algorithm. When an iowait task is enqueued, the governor receives a SCHED_CPUFREQ_IOWAIT event, updates an internal boost value, and may replace the computed utility with the boosted value. The boost decays if no further I/O activity occurs.

6. Limit handling – Frequency limits imposed by other kernel modules (e.g., PM QoS) are propagated to the cpufreq core, which notifies sugov via sugov_limits . Depending on fast‑switch capability, the governor either applies the limits immediately or merely flags that a limit change has occurred, to be handled on the next util update.

7. Start, stop and exit – sugov_start initializes per‑CPU and per‑policy data, registers update hooks, and enables fast‑switch if supported. sugov_stop removes the update hooks and may invoke sugov_exit to free resources, including tunables and any kernel threads used for slow‑switch paths. Finally, sugov_exit disconnects the governor from the cpufreq framework and releases all allocated memory.

The article concludes that while the schedutil governor is the default and generally effective, it still has shortcomings on mobile platforms, and ongoing work by hardware vendors aims to improve cpufreq governors further.