Scenario: Branch Mispredict Storm

Scenario

A latency-critical service regresses after a code merge that increases unpredictable control flow. Branch MPKI doubles, ROB stays underfilled, and retire IPC collapses.

OBSERVED METRIC
front-end bound cycles spike after a workload release

45-MINUTE INTERVIEW FLOW
0-5: define workload and KPI
5-15: map first stage loss and mechanism
15-25: identify proving artifacts
25-35: propose bounded fix with owner
35-45: state validation matrix and rollback

Common pitfalls

• Assume execution units are the bottleneck without predictor evidence

• Tune compiler flags before validating BTB/RAS and indirect branch behavior

• Ignore recovery bandwidth and flush depth when estimating impact

Scenario debrief

Score responses on workload framing, first-failing-stage identification, fix boundedness, and regression discipline.

workload intent -> pipeline behavior -> measured bottleneck -> owner fix

IPC/CPI trend

Debrief prompts

1. Which stage or protocol shows first sustained failure evidence?

2. Which owner can apply the smallest safe fix?

3. Which benchmark + counter pair proves closure in production conditions?

Key takeaways

• Always connect microarchitectural counter changes to product workload outcomes.

• Lock binary, compiler, firmware, and thermal metadata before comparing CPU traces.

Common pitfalls

• Treating average IPC as sufficient proof while ignoring latency tails and outliers.

• Applying predictor or prefetch tweaks without first-failing-stage attribution.

• Declaring closure without reproducible perf, correctness, and power gates.