Performance Review Checklist

Module 21 · Chapter 21.4 · CHI Design-Review Checklist

Project thread — 21.3 reviewed the verification. 21.4 audits performance; 21.5 is the debug triage checklist.

1. The Review

The performance review is a quantitative audit of a CHI design before tapeout — putting numbers on latency, bandwidth, efficiency, and scaling, and checking each against its target. Correctness and performance are independent: a design can be perfectly correct and still miss its latency or bandwidth goal. This audit finds that gap while it is cheap — while the home count, directory, SLC, and QoS can still change — not in silicon, where the numbers are fixed.

2. When To Run It

Run the performance audit at the pre-tapeout gate — after functional verification, on a performance-representative model.

• Trigger: the design is functionally verified (Chapter 21.3) and a performance model / RTL benchmark exists.
• Precondition: realistic workload traces and the performance targets (latency, bandwidth, QoS) are defined.
• Output: a meets-target sign-off, or a list of performance gaps to close before the design freezes.
• Cost of skipping: a design that is correct but slow ships — and performance is structural, so it cannot be patched later.

3. Key Terms

4. Previous Chapter Connection

This review is Module 15, applied. Latency anatomy (Chapter 15.1), memory bandwidth (Chapter 15.4), directory efficiency (Chapter 15.5), snoop reduction (Chapter 15.6), home distribution (Chapter 15.3), and hotspots (Chapter 15.7) each become a measured review area. The case studies (Module 20) supply the targets — a mobile power budget, a server NUMA profile.

Where 21.1–21.3 established the design is right, clean, and verified, 21.4 asks the orthogonal question: is it fast enough? A functionally flawless block can still stall on a hot home or a latency-bound pattern. This review adds the measurement discipline — numbers against targets — and it feeds the debug review (Chapter 21.5), where a missed target becomes a performance bug to triage.

5. How To Use This Checklist

The method — measure the real workload, not a peak.

1. Define the target and the workload first. Each area's tick needs a number vs a target, measured on a representative trace — not a synthetic best case.
2. Walk the seven areas (sections 7–13). Each - [ ] box needs a measurement, not an estimate or a hope.
3. Look at the distribution, not the mean — the tail (slow accesses, hot links) is what real software feels.
4. Find the bottleneck — the one resource that saturates first sets the ceiling; optimize that, not a non-binding metric.
5. Log gaps as performance issues — a missed target is a blocking issue while the structure can still change.

6. The Review Areas

The seven areas of a CHI performance audit, and what each measures.

Each area below is a checklist plus the why. A tick means a measurement met the target — not that the design seems fast.

7. Checklist — Latency

• Access latency is measured on a representative workload and meets the target (Chapter 15.1).
• The latency distribution — not just the mean — is examined; the tail is bounded.
• Critical-path transactions (a load a core stalls on) are identified and their latency prioritized.
• Distant-home / cross-die latency is quantified and within budget (Chapters 15.1, 20.6).
• Latency under load (not just idle) is measured — queuing delay is included.

Why. For a CPU, latency is what software feels (Chapters 15.1, 20.6). An idle or average latency hides the tail — and the tail is where real workloads stall, so the review reads the distribution, not one number.

8. Checklist — Bandwidth & Throughput

• Sustained (not peak) bandwidth on realistic traffic meets the target (Chapter 15.4).
• The memory-bandwidth knee is characterized — where added load stops yielding throughput.
• Link utilisation is measured — no channel is a hidden bottleneck at target load.
• Read vs write and coherent vs I/O bandwidth are separately validated.
• Throughput is measured at the bottleneck, not at an over-provisioned stage.

Why. Sustained bandwidth — not the peak on the datasheet — is what the design delivers (Chapter 15.4). Peak is a vanity number; the knee and the bottleneck determine real throughput.

9. Checklist — Directory & Snoop Efficiency

• The directory / snoop filter is sized so its miss/eviction rate is acceptable (Chapter 15.5).
• Targeted-snoop rate is high — the design snoops sharers, not broadcasts (Chapter 15.6).
• Snoop traffic is measured and within the fabric budget under load.
• Directory-induced back-invalidations (from filter pressure) are quantified — not a silent latency tax.
• Efficiency holds at the target sharer count — not just for lightly-shared lines.

Why. Directory and snoop efficiency decide coherence cost (Chapters 15.5–15.6). A too-small filter or a broadcast-happy design floods the fabric — a performance loss that a functional test never shows.

10. Checklist — Home Distribution & Hotspots

• Per-home and per-link load is measured and balanced — no hotspot (Chapters 15.3, 15.7).
• The address-interleaving function is validated on the real access pattern, not a uniform assumption.
• The busiest home/link, not the average, is checked against capacity — the hotspot caps throughput.
• Striping / hashing avoids pathological alignment (e.g. power-of-two strides hitting one home).
• Distribution holds under the actual workload's spatial locality, not just random addresses.

Why. A hotspot caps the whole system while the average looks fine (Chapter 15.7). This is the classic performance trap — invisible in aggregate numbers — so the review checks the busiest resource, not the mean.

11. Checklist — System-Level Cache

• The SLC hit rate on the target workload meets expectation — it is cutting memory traffic (Chapter 15.5).
• SLC size is validated against the workload's reuse — not guessed.
• The memory-traffic reduction from the SLC is measured, not assumed.
• SLC latency (hit path) is within budget — a slow SLC undercuts its benefit.
• SLC behavior under thrash (poor-reuse workloads) does not collapse to worse-than-no-cache.

Why. The SLC is the main lever against distant-memory latency (Chapters 15.5, 20.6). An undersized or low-hit SLC lets accesses fall through to memory — the dominant latency term — so its hit rate must be measured, not hoped.

12. Checklist — QoS & Fairness

• QoS priorities deliver the intended differentiation — high-priority traffic meets its latency target under load.
• No starvation — every requester makes forward progress, even low-priority, even under contention.
• Arbitration is fair within a priority class — no requester is systematically disadvantaged.
• Priority inversion cannot occur — a low-priority holder cannot block a high-priority waiter indefinitely.
• QoS behavior is validated under saturation, where it actually matters.

Why. QoS is only real under load (Chapters 13–14 flow control). A scheme that looks fine when idle can starve or invert under contention — precisely when the guarantees are needed.

13. Checklist — Scalability & NUMA

• Latency and throughput vs scale are projected — behavior at 2× / 4× agents is quantified (Chapter 20.6).
• NUMA effects are measured — the design exposes locality, and distant access cost is budgeted (Chapter 15.1).
• Cross-die traffic volume and cost are within plan — kept rare (Chapter 20.6).
• The scaling bottleneck (fabric, homes, memory) is identified before it binds.
• Performance is validated at the target scale, not only a small configuration.

Why. At scale, throughput scales but latency governs (Chapter 20.6). A design tuned on a small config can stall at full scale from NUMA — so the audit must project to the target size, not extrapolate from a toy.

14. A Worked Review

Applying the checklist to a mesh interconnect at target load.

1. Bandwidth (8). Aggregate throughput hits 95% of peak — a great vanity number. But it is measured on uniform-random traffic. Finding: not the real workload. Re-measure on the trace.
2. Hotspots (10). On the real trace (with spatial locality), one home carries 4× the average — a hotspot capping delivered throughput at ~40% of the vanity peak. Finding: re-hash the interleave. Blocking issue.
3. Latency (7). Mean latency is fine; the 99th-percentile tail (to the hot home) misses the target. Finding: fixed by the re-hash above.
4. SLC (11). Hit rate meets target; memory traffic cut as expected. Tick.
5. QoS (12). Under saturation, low-priority DMA starves. Finding: arbitration weight fix. Blocking issue.
6. Scale (13). Projected to 2×, the hot home worsens. Finding: the re-hash also helps scale.

The 95%-of-peak headline was a vanity benchmark: the real workload delivered ~40% because of a hotspot the aggregate number hid. Measuring the workload and the tail — not the peak — found it.

15. Sign-off Criteria

What "the design meets performance" actually means.

• All seven areas measured on a representative workload, each meeting its target — not a peak number.
• The latency tail (not just the mean) is within budget.
• No hotspot — the busiest home/link is within capacity on the real access pattern.
• QoS holds under saturation — no starvation, no inversion.
• Performance is validated at target scale, and every performance gap is closed before freeze.

16. The Pitfall

17. Common Mistakes & Red Flags

• Peak-throughput sign-off. Assumption: peak = performance. Bug: real workload stalls (the Pitfall). Fix: measure the trace.
• Average latency only. Assumption: mean is enough. Bug: the tail stalls software. Fix: read the distribution.
• Uniform-traffic assumption. Assumption: addresses are even. Bug: a hidden hotspot. Fix: real spatial locality.
• QoS tested idle. Assumption: fine when idle, fine under load. Bug: starvation under saturation. Fix: test saturated.
• Small-config extrapolation. Assumption: scales linearly. Bug: NUMA stall at target scale. Fix: project to full scale.
• Red flag — one home at 4× average. A throughput-capping hotspot; re-hash the interleave.
• Red flag — "95% of theoretical." Ask: on what traffic? Re-measure on the workload.
• Red flag — no tail number. A mean without a p99 hides the stalls; plot the distribution.

18. Quick Revision

Performance Review Checklist. A quantitative, pre-tapeout audit of a CHI design against its performance targets — because correctness and performance are independent: a design can be perfectly correct and still miss latency or bandwidth, and the gap is cheapest to fix before the home count, directory, SLC, and QoS freeze. Run it on a performance-representative model with realistic traces and defined targets. Walk seven areas, each ticked against a measurement that met a target (not a peak): Latency (distribution and tail, under load, Chapter 15.1); Bandwidth & Throughput (sustained not peak, the knee, the bottleneck, Chapter 15.4); Directory & Snoop Efficiency (filter sizing, targeted-snoop rate, Chapters 15.5–15.6); Home Distribution & Hotspots (the busiest home/link, real access pattern, Chapters 15.3/15.7); System-Level Cache (hit rate, memory-traffic cut, Chapter 15.5); QoS & Fairness (no starvation/inversion under saturation); and Scalability & NUMA (project to target scale, Chapter 20.6). Sign-off means all areas meet target on a representative workload, the tail is bounded, no hotspot, QoS holds saturated, validated at scale. The pitfall is the vanity benchmark — signing off on a peak/aggregate number (95% of theoretical, average idle latency) that flatters but does not reflect the real workload, so a design that hits its synthetic peak delivers half under real contention, a hot home, or a latency-bound pattern. Peak is not delivered performance — measure the workload, the tail, and the true bottleneck. Next, 21.5 is the debug triage checklist for when a bug fires.

Coming Next

Chapter 21.5 — Debug Review Checklist. The design is fast enough; the next checklist is for the moment something breaks. Chapter 21.5 covers the triage checklist when a CHI bug fires — how to classify the symptom, capture the right trace, and localize a hang, a data corruption, an ordering violation, a performance regression, or a RAS event, turning the whole debugging track (Module 18) into a fast, systematic first response.