Scenario: Cache Thrash

Scenario

A multicore analytics workload scales in synthetic tests but degrades in production where working sets overlap. Coherence traffic and LLC evictions surge during peak windows.

OBSERVED METRIC
LLC miss rate and memory latency tails explode under production traffic

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

• Rely on average latency instead of p95/p99 memory behavior

• Blame DRAM speed without checking interference and cache residency

• Skip NUMA placement and prefetch aggressiveness validation

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.