docs/perf/psci-performance-juno.rst

25 Juno supports CPU, cluster and system power down states, corresponding to power
46 ``CPU_SUSPEND`` to deepest power level
49 .. table:: ``CPU_SUSPEND`` latencies (µs) to deepest power level in
68 .. table:: ``CPU_SUSPEND`` latencies (µs) to deepest power level in
87 .. table:: ``CPU_SUSPEND`` latencies (µs) to deepest power level in
106 .. table:: ``CPU_SUSPEND`` latencies (µs) to deepest power level in
125 ``CPU_SUSPEND`` to power level 0
128 .. table:: ``CPU_SUSPEND`` latencies (µs) to power level 0 in
147 .. table:: ``CPU_SUSPEND`` latencies (µs) to power level 0 in
166 .. table:: ``CPU_SUSPEND`` latencies (µs) to power level 0 in serial (v2.14)
185 .. table:: ``CPU_SUSPEND`` latencies (µs) to power level 0 in serial (v2.13)
207 core to the deepest power level.
291 In the results below, CPUs 0-3 refer to CPUs in the little cluster (A53) and
292 CPUs 4-5 refer to CPUs in the big cluster (A57). In all cases CPU 4 is the lead
295 ``PSCI_ENTRY`` corresponds to the powerdown latency, ``PSCI_EXIT`` the wakeup latency, and
298 ``CPU_SUSPEND`` to deepest power level on all CPUs in parallel
318 observed due to TF PSCI lock contention. In the worst case, CPU 3 has to wait
319 for the 3 other CPUs in the cluster (0-2) to complete ``PSCI_ENTRY`` and release
323 last CPUs in their respective clusters to power down, therefore both the L1 and
327 because the L2 cache size for the big cluster is lot larger (2MB) compared to
330 ``CPU_SUSPEND`` to power level 0 on all CPUs in parallel
350 variance in ``PSCI_ENTRY`` times across CPUs is due to lock contention in Juno
351 platform code. The platform lock is used to mediate access to a single SCP
353 AP CPU to enter WFI before making the channel available to other CPUs, which
357 possible to make the ``PSCI_ENTRY`` times smaller and consistent.
365 ``CPU_SUSPEND`` to deepest power level on all CPUs in sequence
386 test. The ``CPU_SUSPEND`` call powers down to the cluster level, requiring a
391 to the little cluster (1MB).
394 CPU 4 continues to run while CPU 5 is suspended. Hence CPU 5 only powers down to
397 ``CPU_SUSPEND`` to power level 0 on all CPUs in sequence
417 only necessary to flush the cache to power level 0 (L1). This is the best case
421 for the CPUs in little cluster due to greater CPU performance.
424 cluster remains powered on throughout the test and there is less code to execute
425 on power on (for example, no need to enter CCI coherency)
427 ``CPU_OFF`` on all non-lead CPUs in sequence then ``CPU_SUSPEND`` on lead CPU to deepest power level
434 2. Program wake up timer and suspend the lead CPU to the deepest power level.
436 3. Call ``CPU_ON`` on non-lead CPU to get the timestamps from each CPU.
456 powers down to the cluster level, requiring a flush of both L1 and L2 caches.
459 lead CPU 4 is running and CPU 5 only powers down to level 0, which only requires
464 to the little cluster (1MB).
467 for CPUs in the little cluster due to greater CPU performance.  These times
469 because there is more code to execute in the "on finisher" compared to the
494 The times for the big CPUs are less than the little CPUs due to greater CPU
497 We suspect the time for lead CPU 4 is shorter than CPU 5 due to subtle cache