Performance Counters and Telemetry — Extended Case Study

Extended case study

A review is called because a workload regresses after a Performance Counters and Telemetry change.

Background

A stable baseline existed until a Performance Analysis change improved one benchmark and regressed a product workload on Counter integrity and stall attribution dashboard.

Symptoms observed

• Regression in Counter integrity and stall attribution dashboard

• Sim vs silicon disagreement

• Pressure to revert or ship risk

Investigation timeline

1. Freeze tags

2. Reproduce

3. Cluster

4. Experiment

5. Validate

6. Memo

Root cause

A hidden assumption in Performance Counters and Telemetry failed under an unrepresented workload phase.

Fix and validation

• Lock workload revision, run window, DVFS state, and collection method.

• Check event aliasing, overflow behavior, and denominator definitions.

• Cross-correlate with trace slices and known microbenchmark signatures.

• Remove counters that fail consistency checks under controlled replay.

• Publish a revised attribution map with confidence levels.

Lessons learned

• Workload coverage beats clever microarchitecture

• Every change needs rollback triggers

CASE STUDY — Performance Counters and Telemetry
baseline/regressed/fixed metrics

Architecture deep dive

PMU evidence beats intuition for architecture decisions.

Concept diagram

TOP-DOWN PERFORMANCE METHOD

Total cycles
 ├─ Retiring useful work
 ├─ Frontend bound
 ├─ Bad speculation
 ├─ Backend core bound
 └─ Backend memory bound

Only after classification should you propose cache, branch, pipeline, or NoC changes.

Metric graph

ROOFLINE SKETCH

Performance
  ^
  |                     compute roof
  |-------------------------------
  |                   /
  |                 /
  |               /   ● workload A (compute-bound)
  |             /
  |   ● workload B (memory-bound)
  +---------------------------------> arithmetic intensity
        memory bandwidth slope

Metrics and artifacts

• PMU event sets

• roofline chart

• top-down stall breakdown

• workload sensitivity matrix

Mini case study

Team proposed wider SIMD but roofline showed memory-bound kernel — bandwidth upgrade and locality fix delivered 2× speedup at lower area cost.

Debug branches

• If counters disagree with sim, align workload and warmup.

• If bottleneck unclear, use top-down method before microarch tweaks.

Senior review question

Ask: what single metric would prove this concept is working or failing on your workload?

Key takeaways

• Connect every architecture claim to a workload and measurable metric.

• State verification and PPA impact before proposing design changes.

Common pitfalls

• Feature-driven design without MPKI/IPC/bandwidth evidence.

• Ignoring coherency and NoC traffic in cache and accelerator sizing.

Study notes

Re-read this topic with one concrete workload.