Simpleperf PMU Event Ambiguity on ARM (Qualcomm) Prevents Accurate Top-Down Analysis

[edisonchan]

Description

I am trying to perform a standard Top-Down Microarchitecture Analysis (TMA) on a Qualcomm Snapdragon 8 Gen 3 device (Phoenix core) using simpleperf stat. The collected performance counter data contains logical contradictions that make it impossible to derive a coherent model. The core issue is that the raw-stall-slot-* event family does not behave as required for TMA, suggesting overlapping event definitions or incorrect assumptions about their scope.

Steps to Reproduce

1. Run a CPU-intensive workload (e.g., ./7zzs b) on a Qualcomm Snapdragon 8 Gen 3 device.
2. Collect key TMA events with a command like:

   simpleperf stat --cpu 7 -e raw-stall,cpu-cycles,instructions,branch-instructions,branch-misses,raw-stall-slot,raw-stall-slot-backend,raw-stall-slot-frontend,raw-stall-frontend,raw-stall-backend taskset -a 80 ./7zzs b

3. Attempt to calculate the four TMA L1 categories (Retiring, Bad Speculation, Front-End Bound, Back-End Bound) from the results.

Expected Result

The sum of the four L1 categories should be close to 100%. The events raw-stall-slot-frontend and raw-stall-slot-backend should be mutually exclusive subsets of raw-stall-slot.

Actual Result

The collected data shows severe logical inconsistencies. Using the provided output as an example:

Performance counter statistics:

#           count  event_name                # count / runtime
   36,554,250,819  raw-stall                 # 2.264 G/sec
   69,656,860,191  cpu-cycles                # 4.314645 GHz
  112,886,642,806  instructions              # 6.992 G/sec
    8,071,984,562  branch-instructions       # 499.990 M/sec
      917,956,488  branch-misses             # 56.860 M/sec
  310,875,425,026  raw-stall-slot            # 19.256 G/sec
  133,569,545,216  raw-stall-slot-backend    # 8.273 G/sec
  179,401,713,413  raw-stall-slot-frontend   # 11.112 G/sec
   19,858,046,770  raw-stall-frontend        # 1.230 G/sec
   16,696,214,013  raw-stall-backend         # 1.034 G/sec

Total test time: 16.150020 seconds.

The following contradictions are present:

1. raw-stall-slot does not represent total wasted slots.

The fundamental TMA axiom is: Total_Slots = instructions + All_Wasted_Slots.

• Calculated: 112,886,642,806 + 310,875,425,026 = 423,762,067,832 slots
• Theoretical Max (cycles * width=10): 69,656,860,191 * 10 = 696,568,601,910 slots

The calculated value is only ~60% of the theoretical maximum, indicating raw-stall-slot is not counting all wasted slots (e.g., it may exclude slots wasted by bad speculation).

2. raw-stall-slot-* events are not mutually exclusive.

The sum of the sub-components exceeds the total, which is logically impossible if they are mutually exclusive:

• raw-stall-slot-backend + raw-stall-slot-frontend = 133,569,545,216 + 179,401,713,413 = 312,971,258,629
• This value is greater than raw-stall-slot (310,875,425,026).

Request

To enable accurate performance analysis, we need:

1. Clarification: Official documentation for the semantics of these events on supported platforms (especially Qualcomm). Specifically:

   • What does raw-stall-slot actually encompass?
   • Why do the sub-components (raw-stall-slot-frontend, raw-stall-slot-backend) overlap?

2. Guidance: A vendor-recommended formula for performing TMA using the events that simpleperf actually provides on this platform.

3. Improvement: If the current events are insufficient, could simpleperf be extended to provide derived metrics that correctly and non-overlappingly calculate the four TMA L1 categories?

Environment

• Device SOC: Qualcomm Snapdragon 8 Elite (Phoenix core)
• Analysis Method: Top-Down Microarchitecture Analysis (TMA)
• **simpleperf Version: ** Simpleperf version 1.build.compiler09051421

This issue prevents any reliable architectural performance analysis on a major Android platform. Thank you for your attention to this matter.

[yabinc]

Not sure what I can answer here.
All the raw events are from ARM architecture manual, as shown in simpleperf list raw comment:
"""
List of raw events provided by cpu pmu:
Please refer to "PMU common architectural and microarchitectural event numbers"
and "ARM recommendations for IMPLEMENTATION DEFINED event numbers" listed in
ARMv9 manual for details.
A possible link is https://developer.arm.com/documentation/ddi0487.
"""

So if anything is unclear, you can check ARM manual. But I agree that ARM leaves many parts as implementation defined.
In the ARM manual:
In a single cycle, the sum of values counted by STALL_SLOT_BACKEND and
STALL_SLOT_FRONTEND might be greater-than slots, if both the backend is unable to accept
some operations and there are fewer-than slots operations available to dispatch from the frontend.

From software's perspective, the kernel is operating PMU events one by one, it can't start and stop all counters exactly at the same time. This can also create some mismatch.

[edisonchan]

Follow-up: Can't compute bad_speculation on Snapdragon 8 Gen 3

Just a quick update based on recent tests with simpleperf on Snapdragon 8 Gen 3 (Phoenix core).

I'm trying to compute bad_speculation using the formula from Arm's C1-Ultra documentation:

(1 - (STALL_SLOT - 10 × IMP_WFX_CLOCK_CYCLES) / (10 × (CPU_CYCLES - IMP_WFX_CLOCK_CYCLES)))
× (1 - OP_RETIRED / OP_SPEC) × 100
+ STALL_FRONTEND_FLUSH / (CPU_CYCLES - IMP_WFX_CLOCK_CYCLES) × 100

But two key events are always zero:

• IMP_WFX_CLOCK_CYCLES (r225)
• STALL_FRONTEND_FLUSH (r8162)

Even under workloads that should trigger them (e.g. 7zzs b), they stay at zero. This makes the formula unusable.

OP_SPEC and OP_RETIRED are available, but without the other components, there's no way to compute bad_speculation.

Request

• Are these events intentionally disabled or not exposed on this platform?
• Is there any alternative way to estimate bad_speculation using available counters?
• Could simpleperf expose derived metrics or enable access to these events?

Would appreciate any guidance. This blocks Topdown analysis on a major Android platform.

Reference: Arm C1-Ultra Topdown L1 metrics

[qianwindz]

@edisonchan

The fundamental TMA axiom is: Total_Slots = instructions + All_Wasted_Slots.

I think this instruction should be replaced with raw input spec, because instructions are rewiring instructions rather than all instructions that use slots