Commit 84a6c759 authored by Pranav-Madhu's avatar Pranav-Madhu Committed by Thomas Abraham
Browse files

infra/common: document steps to validate CPPC and LPI

Add documentation on validating idle states (LPI) and collaborative
processor performance control (CPPC) functionalities on Arm's reference

Change-Id: Ieddd6b1fcec14149da478ab236489d2804529e59
Signed-off-by: Pranav-Madhu's avatarPranav Madhu <>
parent 0dd9e54a
CPPC on Neoverse Reference Design platforms
.. contents::
Overview of CPPC test
Collaborative Processor Performance Control (CPPC) is a mechanism for the OS to
manage the performance of the processor core on a contiguous and abstract
performance scale. The CPPC support as implemented for Neoverse Reference Design
platforms requires the CPUs to support the Arm v8.4 AMU functionaliry. So the
support for CPPC is applicable for platforms that have Arm v8.4 or higher CPU.
The CPPC kernel framework has two parts, monitoring the CPU performance and
scale the CPU performance. In the monitoring part, the OS uses the AMU extension
which is introduced in ARMv8.4. Especially the 'Processor frequency counter'
and the 'Constant frequency counter'. For calculating the processor frequency,
the values of the processor frequency counter and constant frequency counter
are captured at two instances, say 2 microseconds between the instances and get
the delta between these two counts. The constant frequency is known hence the
processor frequency is calculated as:
(delta processor frequency count / delta constant frequency count)
* constant frequency
In the controlling part, the OS requests the desired performance to the platform
firmware through a non-secure channel between the OS and platform firmware.
This document focus on the procedure to validate CPPC functionality, obtaining
the CPU's current operating frequency, procedure to scale CPU frequency and the
scaling governor.
Download and build the required platform software
For downloading and building the platform firmware, refer `Busybox boot`_ or
`Buildroot boot`_ documentation. To enable CPPC from ACPI, update the
``CPPC_EN`` variable from ```` before build.
Changing the scaling governor
For changing the frequency governor, the procedure is:
1. Boot the platform to command line prompt.
2. Read the scaling governor entry to get the current governor in action.
cat /sys/devices/system/cpu/cpufreq/policy<x>/scaling_governor
For RD platforms, x = 0, 1, 2, ... (number of CPUs - 1)
3. Read the scaling available governors entry to get list of supported
cat /sys/devices/system/cpu/cpufreq/policy_x/scaling_available_governors
4. To change governor, write the preferred governor to scaling governor entry.
echo governor_name > /sys/devices/system/cpu/cpufreq/policy<x>/scaling_governor
Here the governor_name is obtained from step 3.
5. Repeat step 3 to confirm the governor change is taken into effect.
Validating CPPC functionality
For validating the CPPC functionality, it is recommended to use 'userspace'
governor. The procedure for validation is:
1. Set 'userspace' governor as the scaling governor.
echo userspace > /sys/devices/system/cpu/cpufreq/policy<x>/scaling_governor
2. Write the desired frequency in KHz to the scaling setspeed entry.
echo freq_in_KHz > /sys/devices/system/cpu/cpufreq/policy<x>/scaling_governor
For RD-V1 variants, the supported frequencies in GHz are 1.3, 1.5, 1.7, 2.1 and 2.6
For RD-N2 variants, the supported frequencies in GHz are 2.3, 2.6 and 3.2
3. Read the cpuinfo current frequency entry, to obtain the current operating
frequency of the CPU, using the AMU extension.
Additional precautions for FVP based platforms
The CPPC frequency monitoring part should be executed with highest time
precision. For FVP based platforms, to improve the time precision, follow the
steps below.
1. Export these variables before launching the model
2. Pass ``--quantum=1`` as model parameter.
3. For single-chip platforms, pass ``--min-sync-latency=0`` and for multichip
platforms, pass ``--min-sync-latency=1`` also as model parameter.
*Copyright (c) 2021, Arm Limited. All rights reserved.*
.. _Busybox boot: docs/infra/common/buildroot-boot.rst
.. _Buildroot boot: docs/infra/common/buildroot-boot.rst
LPI on Neoverse Reference Design platforms
.. contents::
Overview of LPI test
ACPI Low Power Idle (LPI) mechanism allows an operating system to manage the
power states of the processor power domain hierarchy. Neoverse Reference Design
platforms support the c-states c0 (run state), c1 (WFI) and c3 (WFI with core
powered down).
This document describes the procedure to validate LPI functionality, determining
the number of times a particular CPU core switched to idle state and the total
time the core has been in a idle state.
Download and build the required platform software
For downloading and building the platform firmware, refer `Buildroot boot`_.
To enable LPI from ACPI, update the ``LPI_EN`` variable from
```` before build. Also remember to enable stress-ng binary
from the buildroot config.
Procedure for validating LPI states
1. Boot the platform to buildroot command line prompt.
2. Run the command 'nproc' to get the cpu count in the system.
3. Read the idle state descriptor entry to know about the c-state information.
cat /sys/devices/system/cpu/cpu<x>/cpuidle/state<j>/desc
Here, x = 0, 1, 2, ... (nproc -1)
y = 0, 1, 2, ...
generally for RD platform:
state0: c1 (LPI1) state for CPUx
state1: c3 (LPI3) state for CPUx
state2: available only for plaforms having power control for CPU container
and is the combined c3 (LPI3 for core and LPI2 for cluster) state for CPU
and cluster.
4. To get the LPI statistics, read the 'usage' and 'time' entries:
cat /sys/devices/system/cpu/cpu<x>/cpuidle/state<y>/usage
cat /sys/devices/system/cpu/cpu<x>/cpuidle/state<y>/time
5. Wake up all CPUs from sleep. The example shown below uses the 'stress-ng'
utility. Run stress-ng utility for one second for all CPUs using the command
stress-ng -c <num_cpu> -t 1
Here num_cpu is the value obtained on step 2
6. Repeat step 4 and compare the usage and time values.
In a system with idle states enabled, the expectation is the 'usage' count
should increment on each suspend-resume cycle. The value for 'time' specifies
the total time period the core was in that particular state.
Note: In a system that supports state2, the usage count will increment for
either state1 or for state2. This is applicable when a core is the last one to
undergo sleep inside a container, then the core will request for a combined
sleep state instead of core only power down.
*Copyright (c) 2021, Arm Limited. All rights reserved.*
.. _Buildroot boot: docs/infra/common/buildroot-boot.rst
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment