# Features
Source: [https://docs.qualcomm.com/doc/80-70015-10/topic/2-performance-features.html](https://docs.qualcomm.com/doc/80-70015-10/topic/2-performance-features.html)
The Qualcomm Linux kernel includes features, such as the CPU scheduler, CPU frequency
governor, dynamic voltage and frequency scaling (DVFS), and memory management. This
guide provides an overview of each feature and related reference links. Additionally,
Qualcomm has added a feature called PerfHAL to enhance performance.
## CPU scheduler
Source: [https://docs.qualcomm.com/doc/80-70015-10/topic/2-performance-features.html](https://docs.qualcomm.com/doc/80-70015-10/topic/2-performance-features.html)
The CPU scheduler manages how CPU time is distributed among the processes running on
Linux systems.
It uses the earliest eligible virtual deadline first (EEVDF) scheduler, a feature
provided by the Linux kernel. The EEVDF CPU scheduler uses per entity load tracking
(PELT) to monitor the task load.
For more information, see:
- [An
EEVDF CPU scheduler for Linux](https://lwn.net/Articles/925371/)
- [Per-entity load tracking \[LWN.net\]](https://lwn.net/Articles/531853/)
Utilization clamping (UCLAMP or util clamp) is a scheduler feature that helps manage
performance requirements for tasks.
For more information, see:
- [https://docs.kernel.org/scheduler/sched-util-clamp.html](https://docs.kernel.org/scheduler/sched-util-clamp.html)
- [Customize CPU scheduler](https://docs.qualcomm.com/doc/80-70015-10/topic/18-customize.html#customize-scheduler)
## CPU frequency governor
Source: [https://docs.qualcomm.com/doc/80-70015-10/topic/2-performance-features.html](https://docs.qualcomm.com/doc/80-70015-10/topic/2-performance-features.html)
A CPU frequency governor adjusts the CPU frequency based on the task load. The CPU
scheduler provides the necessary inputs for this process.
Qualcomm Linux uses the `schedutil` governor, a feature provided by the
Linux kernel.
This governor increases the frequency when the system is heavily loaded and reduces it
when the load is low, ensuring an optimal balance between power consumption and
performance.
For more information, see:
- [https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt](https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt)
- [Configure CPU](https://docs.qualcomm.com/doc/80-70015-10/topic/14-configure.html#cpu)
- [Customize CPU frequency governor](https://docs.qualcomm.com/doc/80-70015-10/topic/18-customize.html#cpu-frequency-governer)
## DVFS governors
Source: [https://docs.qualcomm.com/doc/80-70015-10/topic/2-performance-features.html](https://docs.qualcomm.com/doc/80-70015-10/topic/2-performance-features.html)
DVFS governors control the frequencies of CPU caches (L3), the last level cache
controller (LLCC), and the DDR based on the system workload.
These governors increase the frequency when the workload is high and decrease it when the
workload is low, ensuring an optimal balance between power consumption and
performance.
Qualcomm Linux supports two types of DVFS governors for L3 cache, LLCC, and DDR.
### Static map DVFS governor
This governor aligns the frequencies of the CPU L3 cache and DDR with the current CPU
frequency to balance power and performance requirements.
For example, if the CPU frequency is at its maximum, the L3 cache and DDR frequencies
must also be at their maximum levels.
The static mapping is available in the source code at
arch/arm64/boot/dts/qcom/<target>.dtsi.
For customization options, see [Customize static map DVFS governor](https://docs.qualcomm.com/doc/80-70015-10/topic/18-customize.html#dvfs_0__section_u1x_jps_51c_caharris_03-20-24-2005-37-832).
### BWMON governor
The bandwidth monitoring (BWMON) governor dynamically adjusts the frequencies of the
LLCC and DDR based on the measured traffic flow from the CPU to the LLCC and then to
the DDR.
The BWMON hardware block measures this traffic. It monitors the data throughput
between memory and other subsystems within a specified sampling window and uses this
information to scale the LLCC and DDR frequencies to meet the required
bandwidth.
The BWMON governor driver is available in the source code at
drivers/soc/qcom/icc-bwmon.c.
For more information, see:
- [\[PATCH v3 0/4\] soc/arm64: qcom: Add initial
version of bwmon](https://lwn.net/ml/linux-kernel/20220531105137.110050-1-krzysztof.kozlowski@linaro.org/)
- [Customize BWMON governor](https://docs.qualcomm.com/doc/80-70015-10/topic/18-customize.html#dvfs_0__section_qxs_4ps_51c_caharris_03-20-24-2007-2-926)
## PerfHAL
Source: [https://docs.qualcomm.com/doc/80-70015-10/topic/2-performance-features.html](https://docs.qualcomm.com/doc/80-70015-10/topic/2-performance-features.html)
PerfHAL is a Qualcomm proprietary service that offers added functionality by making
perflock APIs accessible. It is beneficial when you need short-term performance enhancements
or power savings.
Perflocks help in modifying system behavior to manage intermittent workloads. For
example, if a specific code segment must run at a higher CPU frequency for a certain
duration, perflocks can be used within that code to boost the CPU frequency.
PerfHAL efficiently handles concurrent perflock requests from multiple clients. When
several requests are aimed at the same resource, PerfHAL aggregates them to achieve the
optimal performance level needed by the device.
When a perflock of a client is no longer active, PerfHAL releases all the perflocks
associated with that client.
### Perflock APIs
Source: [https://docs.qualcomm.com/doc/80-70015-10/topic/2-performance-features.html](https://docs.qualcomm.com/doc/80-70015-10/topic/2-performance-features.html)
Perflock APIs are designed to allow applications to adjust system parameters for
specific use cases, helping them meet their performance and power objectives.
User space applications use the perf\_lock\_acq() and
perf\_lock\_rel() APIs to request specific values of system tunable
parameters for both, a set or an indefinite time period.
### Acquire perflock
The perf\_lock\_acq() function is used to acquire a perflock with
the necessary optimizations.
The syntax for this function is as follows:
`int perf_lock_acq(int handle, int duration, int list[], int
numArgs)`
Table : perf_lock_acq API parameters
| Parameter | Description |
| --- | --- |
| `handle` | Identifies the client request. |
| `duration` |
Indicates the maximum timeout period that a perflock must be held, in milliseconds.
duration parameter can be set for a definite time or for an indefinite time (0).
Definite perflocks require a positive integer value to specify the maximum timeout period. A timer is created and the perflock is released when the timer expires.
Indefinite perflocks are held until the client calls the release function. To manually release a perflock that has been set for an indefinite duration, use the perf_lock_rel() function.
|
| `list` | An array of resource opcodes and value pairs. Opcodes indicate a system parameter (resource) and the value to set it (level). |
| `numArgs` | Number of elements in the list array. |
Table : perf_lock_acq API returns and result
| Returns | Result |
| --- | --- |
| A non-zero integer | Success |
| -1 | Failure |
### Perflock release
The perf\_lock\_rel() function is used to release a perflock that is
held by the perf\_lock\_acq() API. This function is used only for
the perflocks that are set for an indefinite duration. The syntax for this function
is as follows:
`int perf_lock_rel(int handle)`
Table : perf_lock_rel API parameters
| Parameter | Description |
| --- | --- |
| `handle` |
Tracks unique requests
Passes the same handle that perf_lock_acq() returns to release the lock
|
Table : perf_lock_rel API returns and result
| Returns | Result |
| --- | --- |
| A non-zero integer | Success |
| -1 | Failure |
### Resource opcodes
Source: [https://docs.qualcomm.com/doc/80-70015-10/topic/2-performance-features.html](https://docs.qualcomm.com/doc/80-70015-10/topic/2-performance-features.html)
Perflock uses a combination of opcodes and their corresponding values to perform
specific operations on a perflock resource.
The following table lists the supported opcodes:
Note: The opcodes 0x44008200 and 0x4400C200, as well as the
commands containing `policy7` are not supported on QCS9075.
Table : Supported opcodes
| Opcode | Purpose | Sysnode on device |
| --- | --- | --- |
| 0x44000000 | Sets the minimum acceptable performance level for individual tasks and task groups. | /proc/sys/kernel/sched\_util\_clamp\_min |
| 0x44004000 | Sets the maximum acceptable performance level for individual tasks and task groups. | /proc/sys/kernel/sched\_util\_clamp\_max |
| 0x44008100 | Sets the minimum frequency of the Silver cluster. | /sys/devices/system/cpu/cpufreq/policy0/scaling\_min\_freq |
| 0x44008000 | Sets the minimum frequency of the Gold cluster. | /sys/devices/system/cpu/cpufreq/policy4/scaling\_min\_freq |
| 0x44008200 | Sets the minimum frequency of the Prime cluster. | /sys/devices/system/cpu/cpufreq/policy7/scaling\_min\_freq |
| 0x4400C100 | Sets the maximum frequency of the Silver cluster. | /sys/devices/system/cpu/cpufreq/policy0/scaling\_max\_freq |
| 0x4400C000 | Sets the maximum frequency of the Gold cluster. | /sys/devices/system/cpu/cpufreq/policy4/scaling\_max\_freq |
| 0x4400C200 | Sets the maximum frequency of the Prime cluster. | /sys/devices/system/cpu/cpufreq/policy7/scaling\_max\_freq |
The following are some examples of the resource opcodes:
- 0x44004100, 1958400: This pair of opcode and value indicates that the minimum
frequency of the Silver cluster must be set to 1958400 KHz.
- 0x44004100, 1958400, 0x44008100, 2100000: This pair of opcode and value indicates
that the minimum frequency of the Silver cluster must be set to 1958400 KHz. The
maximum frequency of the Silver cluster must be set to 2100000 KHz.
For more information on how to use and debug perflock, see [Customize perflock](https://docs.qualcomm.com/doc/80-70015-10/topic/18-customize.html#customize-perlocks).
## Memory
Source: [https://docs.qualcomm.com/doc/80-70015-10/topic/2-performance-features.html](https://docs.qualcomm.com/doc/80-70015-10/topic/2-performance-features.html)
RAM is used for all memory allocations made by the Qualcomm Linux software. Effective
management of RAM is crucial to meet performance requirements and ensure the smooth
functioning of applications.
Figure : Memory partitioning

Certain sections of RAM are managed independent of the Linux system. For example,
firmware such as modem, video, and audio run from these specific RAM partitions. The
Linux kernel manages all other RAM partitions.
The Linux kernel features its own memory management subsystem, which includes:
- Implementation of virtual memory and demand paging
- Allocation of memory to both kernel internal structures and user space
programs
- Mapping of files into the address space of the processes
- Other memory management operations
### RAM memory partitioning
The following table describes various types of memory allocations.
Note: The commands specified in the following table should be
run on the device.
| RAM classification | Memory segment | Allocation types | Description |
| --- | --- | --- | --- |
| Non-Linux | – | – |
Memory is reserved in the form of carveouts by various subsystems other than Linux.
These carveouts are specified in the respective DTSI files.
The kernel page structure is the memory used by the kernel to maintain page structures for every page of RAM. This is calculated as 16 MB per GB of RAM size.
|
| Linux (system RAM) | Kernel dynamic | Slab |
The slab is used by the kernel for faster and more efficient memory usage of frequently used data structures.
To check the memory usage of the slab, run the following command:
cat /proc/meminfo | grep -i slab
To understand the breakup of various slabs and their usage, enable CONFIG_SLUB_DEBUG in the kernel configuration, and then run the following command:
Buffers are of fixed size and contain blocks of information either read from disk or written to disk.
To check the buffer memory usage, run the following command:
cat /proc/meminfo | grep -i Buffers
|
| Linux (system RAM) | Kernel dynamic | Shmem |
Shared memory is a common block of memory that is mapped into the address spaces of two or more processes.
To check the shared memory usage, run the following command:
cat /proc/meminfo | grep -i shmem
|
| Linux (system RAM) | User space | ZUSED (ZRAM) | An anonymous memory post compression by ZRAM. |
| Linux (system RAM) | User space | CMA |
A physically continuous memory is typically mapped to other IPs, such as video and display, however it is allocated to the runtime.
The free memory that the system can use is reduced with the usage of more CMA reservations. Only the movable allocations, such as user space process allocations can use the CMA reserved free memory. However, it cannot be used for the kernel allocations.
|
| Linux (system RAM) | User space | ANON |
Memory that user space applications allocate using malloc() or new() function calls.
To get the ANON memory breakup for a process, run the following command:
cat /proc/<pid>/smaps
|
| Linux (system RAM) | User space | ION |
ION memory allows sharing buffers between hardware IPs such as video, camera, and Qualcomm Linux software.
ION manages one or more memory pools, which can be set aside at boot time to combat fragmentation.
To check the ION memory usage, run the following commands:
To check the overall kernel graphics support layer (KGSL) memory usage, run the following command:
cat /sys/class/kgsl/kgsl/page_alloc
To check the process level breakup, run the following command:
cat /sys/class/kgsl/kgsl/proc/<pid>/kernel
|
| Linux (system RAM) | Free memory | – |
Free memory is the memory that is not yet used and is available for any allocation.
To check the free memory, run the following command:
cat /proc/meminfo | grep -i MemFree
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
## Real-time kernel
Source: [https://docs.qualcomm.com/doc/80-70015-10/topic/2-performance-features.html](https://docs.qualcomm.com/doc/80-70015-10/topic/2-performance-features.html)
Real-time (RT) Linux is an optional feature that is not enabled by default on
Qualcomm Linux. It can be enabled based on the product requirements.
RT Linux is designed to offer deterministic and predictable behavior for applications
that are time‑sensitive.
### Set up workspace
In Qualcomm Linux, the RT Linux kernel recipes are referred to as
`linux-qcom-base-rt` for base BSP and
`linux-qcom-custom-rt` for custom BSP.
The Qualcomm Linux kernel supports long-term support (LTS) RT kernel v6.6, which is
maintained through the Yocto recipe in the `meta-qcom-realtime` layer
at the following paths in the source code:
- Base BSP:
recipes-kernel/linux/linux-kernel-base-rt\_6.6.bb
- Custom BSP:
`recipes-kernel/linux/linux-kernel-custom-rt_6.6.bb`.
For more information on how to clone the workspace and acquire all the meta layers to
use Qualcomm RT Linux kernel, see [Sync and build with real-time Linux](https://docs.qualcomm.com/bundle/publicresource/topics/80-70015-254/how_to.html#sync-and-build-with-real-time-linux).
### Enable RT kernel
The RT kernel is enabled using the Linux RT kernel recipe. This recipe fetches the
kernel, downloads pre-empt RT patches, and applies them to the kernel. It also
enables a fully pre-emptible kernel with:
`CONFIG_PREEMPT_RT=y`
For more information, see [Qualcomm Linux Kernel Guide](https://docs.qualcomm.com/bundle/publicresource/topics/80-70015-3/overview.html).
### Verify kernel type
After boot up, verify the kernel type by running the following command on the
device:
uname -vCopy to clipboard
The following is an output of the command:
SMP PREMPT_RTCopy to clipboard
Last Published: Oct 14, 2024
[Previous Topic
Getting started](https://docs.qualcomm.com/bundle/publicresource/80-70015-10/topics/get-started.md) [Next Topic
Analysis tools](https://docs.qualcomm.com/bundle/publicresource/80-70015-10/topics/13-performance_tools.md)