8.2.2.1.CPU_SUSPEND to deepest power level

8.2.2.2.CPU_SUSPEND to power level 0

8.2.2.3.CPU_OFF on all non-lead CPUs

CPU_OFF on all non-lead CPUs in sequence then,CPU_SUSPEND on the leadcore to the deepest power level.

8.2.2.4.CPU_VERSION in parallel

8.2.3.1.CPU_SUSPEND to deepest power level on all CPUs in parallel

A large variance inPSCI_ENTRY andPSCI_EXIT times across CPUs isobserved due to TF PSCI lock contention. In the worst case, CPU 3 has to waitfor the 3 other CPUs in the cluster (0-2) to completePSCI_ENTRY and releasethe lock before proceeding.

TheCFLUSH_OVERHEAD times for CPUs 3 and 5 are higher because they are thelast CPUs in their respective clusters to power down, therefore both the L1 andL2 caches are flushed.

TheCFLUSH_OVERHEAD time for CPU 5 is a lot larger than that for CPU 3because the L2 cache size for the big cluster is lot larger (2MB) compared tothe little cluster (1MB).

8.2.3.2.CPU_SUSPEND to power level 0 on all CPUs in parallel

There is no lock contention in TF generic code at power level 0 but the largevariance inPSCI_ENTRY times across CPUs is due to lock contention in Junoplatform code. The platform lock is used to mediate access to a single SCPcommunication channel. This is compounded by the SCP firmware waiting for eachAP CPU to enter WFI before making the channel available to other CPUs, whicheffectively serializes the SCP power down commands from all CPUs.

On platforms with a more efficient CPU power down mechanism, it should bepossible to make thePSCI_ENTRY times smaller and consistent.

ThePSCI_EXIT times are consistent across all CPUs because TF does notrequire locks at power level 0.

TheCFLUSH_OVERHEAD times for all CPUs are small and consistent since onlythe cache associated with power level 0 is flushed (L1).

8.2.3.3.CPU_SUSPEND to deepest power level on all CPUs in sequence

TheCFLUSH_OVERHEAD times for lead CPU 4 and all CPUs in the non-lead clusterare large because all other CPUs in the cluster are powered down during thetest. TheCPU_SUSPEND call powers down to the cluster level, requiring aflush of both L1 and L2 caches.

TheCFLUSH_OVERHEAD time for CPU 4 is a lot larger than those for the littleCPUs because the L2 cache size for the big cluster is lot larger (2MB) comparedto the little cluster (1MB).

ThePSCI_ENTRY andCFLUSH_OVERHEAD times for CPU 5 are low because leadCPU 4 continues to run while CPU 5 is suspended. Hence CPU 5 only powers down tolevel 0, which only requires L1 cache flush.

8.2.3.4.CPU_SUSPEND to power level 0 on all CPUs in sequence

Here the times are small and consistent since there is no contention and it isonly necessary to flush the cache to power level 0 (L1). This is the best casescenario.

ThePSCI_ENTRY times for CPUs in the big cluster are slightly smaller thanfor the CPUs in little cluster due to greater CPU performance.

ThePSCI_EXIT times are generally lower than in the last test because thecluster remains powered on throughout the test and there is less code to executeon power on (for example, no need to enter CCI coherency)

8.2.3.5.CPU_OFF on all non-lead CPUs in sequence thenCPU_SUSPEND on lead CPU to deepest power level

The test sequence here is as follows:

1. CallCPU_ON andCPU_OFF on each non-lead CPU in sequence.

2. Program wake up timer and suspend the lead CPU to the deepest power level.

3. CallCPU_ON on non-lead CPU to get the timestamps from each CPU.

TheCFLUSH_OVERHEAD times for all little CPUs are large because all otherCPUs in that cluster are powerered down during the test. TheCPU_OFF callpowers down to the cluster level, requiring a flush of both L1 and L2 caches.

ThePSCI_ENTRY andCFLUSH_OVERHEAD times for CPU 5 are small becauselead CPU 4 is running and CPU 5 only powers down to level 0, which only requiresan L1 cache flush.

TheCFLUSH_OVERHEAD time for CPU 4 is a lot larger than those for the littleCPUs because the L2 cache size for the big cluster is lot larger (2MB) comparedto the little cluster (1MB).

ThePSCI_EXIT times for CPUs in the big cluster are slightly smaller thanfor CPUs in the little cluster due to greater CPU performance. These timesgenerally are greater than thePSCI_EXIT times in theCPU_SUSPEND testsbecause there is more code to execute in the “on finisher” compared to the“suspend finisher” (for example, GIC redistributor register programming).

8.2.3.6.PSCI_VERSION on all CPUs in parallel

Since very little code is associated withPSCI_VERSION, this testapproximates the round trip latency for handling a fast SMC at EL3 in TF.

The times for the big CPUs are less than the little CPUs due to greater CPUperformance.

We suspect the time for lead CPU 4 is shorter than CPU 5 due to subtle cacheeffects, given that these measurements are at the nano-second level.

Copyright (c) 2019-2025, Arm Limited and Contributors. All rights reserved.