# Configure the scheduler

The Qualcomm Linux kernel supports the standard Linux scheduler solution. The kernel uses the scheduler to choose the right CPU for task placement based on the CPU energy consumption.

The scheduler decides the order in which the processes must run. The scheduler runs the processes from the runqueue of each CPU.

The kernel baseline supports the standard Linux scheduler solution. The kernel uses [Energy Aware Scheduling
(EAS)](https://www.kernel.org/doc/html/next/scheduler/sched-energy.html) to choose the right CPU for task placement based on the CPU energy consumption.

EAS overrides the completely fair scheduler (CFS) task wake-up balancing code. It uses the energy model (EM) of the CPUs and the per entity load tracking (PELT) signals to choose an energy-efficient target CPU during wake-up balance
in a system with asymmetric CPU topology.

For basic scheduler documentation, see [Scheduler](https://www.kernel.org/doc/html/next/scheduler/index.html).

## Understand CPU topology and EAS

The Qualcomm SoCs have a heterogeneous CPU topology that is differentiated in terms of CPU capacity metrics used in EAS.

EAS uses the concept of *capacity* to differentiate CPUs with different
computing capabilities. The capacity of a CPU represents the amount of
work it finishes when running at its highest frequency compared to
the most capable CPU of the system. Capacity values are normalized in a
1024 range (the most powerful CPU/cluster is configured at 1024).

EAS builds the capacity of a cluster based on the Dhrystone million
instructions per second (DMIPS) value specified in the CPU node and the
maximum frequency supported by the cluster.

The following are the `sysfs` nodes for CPU topology and capacity:

> 
> 
> Table: CPU topology and capacity
> 
> 
> | Commands | Purpose |
> | --- | --- |
> | cat /sys/devices/system/cpu/cpu*/cpu_capacity<br>    Copy to clipboard | To get the capacity associated with each CPU in the system. |
> | cat /sys/devices/system/cpu/cpufreq/policy*/related_cpus<br>    Copy to clipboard | To get a list of the CPUs associated with each cluster in the system. |

For more information about how a scheduler uses CPU capacity, see [Capacity
Aware
Scheduling](https://www.kernel.org/doc/html/next/scheduler/sched-capacity.html).

## Change the default CPU frequency governor

The CPU frequency governor can be changed at runtime or set statically
during build compilation.

1. Kconfig configuration option: To set the CPU frequency governor,
enable the corresponding driver in the kernel defconfiguration file.

    To set `PERFORMANCE` governor as the default CPU frequency
governor, set `CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y` in the
defconfiguration file.
2. Kernel command-line option: To override the kernel configuration
option, add a `cpufreq.default_governor=performance` parameter to
the kernel command-line in the
`meta-qcom-hwe/conf/machine/include/qcom-<SoC>.inc` file to set the
appropriate CPU frequency governor.

## Configure the per entity load tracking

Per entity load tracking (PELT) is the mechanism used to track load accounting for `sched_entities/groups/runqueues`.

The PELT clock multiplier is tuned to meet power and performance
requirements.

The command-line parameter `sched_pelt_multiplier` allows you to set a
clock multiplier. The clock multiplier tunes the PELT ramp up/down speed
to tune the system for power and performance.

With lower half-life time, the CPU utilization of tasks is accumulated
faster. The tasks are placed on performance CPUs, thereby leading to better
performance with high power consumption. The CPU utilization also gets
accumulated to select the higher CPU frequency within less time.

Note

The half-life time also affects how the task utilization ramps down. The UTIL EST feature provides faster ramp down.

### PELT multiplier

In the Linux kernel, the PELT half-life multiplier influences how the system adapts to changing workloads and adjusts CPU frequencies based on historical utilization data. It’s a configuration that speeds up the PELT clock and reduces the half-life time, resulting in faster system response.

Configure the PELT multiplier through the kernel command-line argument:

`kernel.sched_pelt_multiplier=[1, 2, 4] Default value: 1 (half life 32 msec), 2 (half life 16msec), 4(half life 8 msec)]`

For more information about PELT, see [Per-entity load
tracking](https://lwn.net/Articles/531853/).

## Configure SchedUtil governor

The SchedUtil CPU frequency governor is the default governor in the Qualcomm
Linux kernel. SchedUtil predicts optimal operating points (OPPs) based on
the CPU utilization, maintaining coherence between frequency requests
and energy predictions.

The SchedUtil CPU frequency governor is tied to EAS, and it tries to
predict at which OPP all the CPUs run next to estimate
their energy consumption.

For more information, see
[SchedUtil](https://www.kernel.org/doc/html/next/scheduler/schedutil.html).

## Configure utilization clamping (UCLAMP)

Utilization clamping is a scheduler feature that allows user space to manage the performance requirements of tasks.

To perform clamping, configure the following parameters:

- `UCLAMP_MIN`: If it’s set to any value `> 0`, the task demand is always greater than or equal to this value. If the actual task demand is more than this value, then the actual demand signal is used, but if the actual task demand is lower than this value, then `UCLAMP_MIN` is reported as the task demand.
- `UCLAMP_MAX`: If it’s set to any value `> 0`, the task demand is always less than or equal to this value. If the actual task demand is less than this value, then the actual demand signal is used, but if
actual task demand is more than this value, then `UCLAMP_MAX` is reported as task demand.

Note

`UCLAMP_MAX > UCLAMP_MIN`

Use the UCLAMP to influence the scheduler’s task placement decisions.

On a heterogeneous system, the scheduler uses the task demand or utilization signal (PELT signal) to classify a task as small or big. Based on the input from the task classification, the scheduler selects small (less computing power) or big (more computing power) CPU cores for task placement with a probable impact on power consumption.

For example, clamp nonimportant (trivial/background/housekeeping) tasks to lower values (`lower UCLAMP_MAX`) to influence the scheduler to place the tasks on the little cluster. Similarly, clamp the important/foreground/active tasks to higher values (`higher UCLAMP_MIN`) to influence the scheduler to place the tasks on the big cluster.

UCLAMP also allows the scheduler to control frequency guidance.

To meet the quick frequency ramp for a task, clamp the task to a higher demand (`UCLAMP_MIN`) value. The higher clamping helps to ramp up the frequency of the cluster to meet the performance requirements of the task.

The UCLAMP operation allows performance management of tasks/task groups from the
user space.

UCLAMP allows the placement of tasks or task groups and allows performance hints or constraints. This mechanism is used to influence the scheduler placement
decisions or to influence the frequency guidance of the cluster.

For more information, see [UCLAMP](https://www.kernel.org/doc/html/next/scheduler/sched-util-clamp.html).
For more information about the interface and configuration, see [Utilization Clamping](https://www.kernel.org/doc/html/v6.6/scheduler/sched-util-clamp.html).

Last Published: Jun 25, 2026

[Previous Topic
Configure and manage memory](https://docs.qualcomm.com/bundle/publicresource/80-70030-3/topics/memory.md) [Next Topic
Configure the dynamic voltage and frequency scaling (DVFS) governors](https://docs.qualcomm.com/bundle/publicresource/80-70030-3/topics/dynamic-clock-and-voltage-scaling-dcvs.md)