Skip to main content
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) 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.

​
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
CommandsPurpose
cat /sys/devices/system/cpu/cpu*/cpu_capacityTo get the capacity associated with each CPU in the system.
cat /sys/devices/system/cpu/cpufreq/policy*/related_cpusTo 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.

​
Change the default CPU frequency governor

The CPU frequency governor can be changed at runtime or set statically during build compilation.
  1. Kconfig configuration: 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: To override the kernel configuration option, add a cpufreq.default_governor=performance parameter to the kernel command-line in the KERNEL_CMDLINE_EXTRA of the kas base configuration file ci/base.yml in the SoC-specific machine inclusion file. For example, meta-qcom/conf/machine/include/qcom-<SoC>.inc file to set the appropriate CPU frequency governor.

​
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.

​
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.
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 non-important (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 and about the interface and configuration, see Utilization Clamping.