AMBA CHI · Module 22 · CHI Misconceptions Engineers Have

“Snoop Filters Are Always Perfect”

The final myth returns to the directory the track leaned on. A snoop filter snoops only caches holding a line — easy to picture as a perfect oracle. It cannot be: it is finite, only approximating the sharer set. It must never miss a real sharer — that would break coherence — so it is conservative and pays twice. It over-approximates, sending a false-positive snoop the cache answers with a miss. And under capacity pressure it evicts an entry, forcing that line out of the caches too — a back-invalidation of a still-useful line. The kernel of truth: a well-sized filter is nearly precise and always correct — perfect for correctness, not precision. The trap is treating it as free.

Advanced16 min readAMBA CHIMisconceptionSnoop FilterBack-InvalidationDirectory

Module 22 · Chapter 22.7 · CHI Misconceptions Engineers Have

Project thread — 22.6 widened CHI's scope. 22.7 closes the module, and the track, on the directory's finite limits.

1. The Misconception

The belief: "a snoop filter is perfect — it exactly tracks which caches hold each line, always." It is the quiet assumption behind every "the directory just knows the sharers" statement — including ones this track made for simplicity. It is an Advanced misconception because it hides two real effects — false-positive snoops and back-invalidations — that only appear when you take the filter's finiteness seriously. A snoop filter is correct, but it is not precise, and it is never free.

2. Why It's Tempting

The belief is tempting because a well-sized filter is nearly perfect — and it is always correct.

It's always correct. A filter never breaks coherence — by construction it never misses a real sharer. So it feels perfect, because "perfect" and "correct" blur together.
A good filter is nearly precise. For typical, well-partitioned workloads, a properly-sized filter tracks sharers accurately — false positives are rare. So "mostly precise" reads as "precise".
We taught it as an oracle. For clarity, the directory is often described as just knowing the sharers (Chapters 15.3–15.6) — a simplification that plants the perfect-oracle image.

The seed is real: the filter is correct and usually precise. The error is turning "correct and usually precise" into "perfectly precise, always, for free".

3. Key Terms

4. Previous Chapter Connection

This chapter is the honest footnote to the whole scalability story. Chapter 22.2 said the directory targets snoops; 22.3 said it does not eliminate them; 22.7 adds that the filter implementing it is finite, so even the targeting is approximate. The directory efficiency (Chapter 15.5) and snoop reduction (Chapter 15.6) material assumed a filter that is good — here we name what happens when it is pressured.

Where the track relied on the directory as an oracle, 22.7 repays that simplification with the truth: the oracle is a finite table that stays correct by being conservative, at the cost of false-positive snoops and back-invalidations. Fittingly, the last myth is about the limits of the mechanism the whole track was built on.

5. The Claim, Precisely

State the myth falsifiably.

Claim: "A snoop filter exactly tracks the sharers — it never indicates a cache that does not hold the line, and it never needs to disturb the caches to manage itself."

Testable. Fill the filter past its capacity for a hot set of addresses. Must it stay correct? Yes. Can it stay exact? No — with fewer entries than live tracked lines, it must either over-approximate (indicate caches that don't hold the line → false-positive snoops) or evict an entry (→ back-invalidation). Either way it deviates from "exact". The claim fails under capacity pressure.

6. Why It's Wrong — The Core

A finite filter cannot be exact; it stays correct by being conservative.

Exactness would need unbounded storage. Tracking every line every cache could hold is unbounded — no real filter has that, so it approximates.
It must never have false negatives. Claiming "no sharer" when one exists would leave a stale copy — a coherence break. So the filter always errs toward too many sharers.
Over-approximation → false-positive snoops. Erring high means the Home snoops caches that don't hold the line; they answer miss — wasted snoop traffic.
Capacity pressure → back-invalidation. To safely drop a filter entry, the line must also leave the caches — so a filter eviction forces a cache eviction, even of a still-useful line.

The filter is perfect for correctness (never breaks coherence) and imperfect for precision (false positives, back-invalidations) — two different properties the myth fuses.

7. Engineering Diagram — the filter over-approximates

Figure 1 — a finite snoop filter stays correct by over-approximating. When it cannot represent the exact sharer set, it errs toward too many: it tells the Home a cache might hold a line it does not, so the Home sends a false-positive snoop the cache answers with a miss. Under capacity pressure it evicts an entry, and to safely forget a line it forces that line out of the caches too — a back-invalidation, the filter evicting a still-useful line.

The filter snoops Cache B (a real sharer — correct), Cache A (a false positive — wasted), and back-invalidates Cache C (a capacity eviction — a still-useful line lost). All correct; none free.

The false-positive snoop, in time — a wasted round-trip:

False-positive snoop — filter over-approximates, cache answers miss

8 cycles

Figure 2 — a false-positive snoop in time. The finite filter over-approximates and reports the cache as a possible sharer, so the Home issues a snoop; the cache looks up the line, does not have it, and answers with a miss. The snoop request and its miss response are real fabric traffic and latency spent on a line the cache never held — the precision cost of a finite filter, invisible to correctness but real to performance.

The snoop went out and came back a miss — real fabric traffic and latency for a line the cache never held. Correctness was never at risk; precision paid the bill.

8. The Mechanism

How a finite filter stays correct, and what it costs.

Situation	Filter behavior	Cost
Exact tracking possible	precise sharer set	none — the ideal case
Cannot represent exactly	over-approximate (err high)	false-positive snoops
Out of capacity	evict an entry	back-invalidation (cache line forced out)
Never allowed	false negative (miss a sharer)	would break coherence — forbidden

The rule to carry: a snoop filter is a conservative, finite approximation — it guarantees no false negatives (correctness) and pays for its finiteness with false positives and back-invalidations (precision). Perfect correctness is required and delivered; perfect precision is impossible and only approached.

9. The Kernel of Truth

Steelman the belief.

It is always correct. The filter never breaks coherence — the property that matters most genuinely is "perfect". The belief correctly senses this.
A well-sized filter is nearly precise. Sized to the working set, false positives and back-invalidations are rare — for many workloads, effectively an oracle.
The simplification is usually fine. Reasoning about the directory as if it were exact is a valid approximation for most analysis — the detail matters only under pressure.

The truth: the filter is perfect where it counts — correctness — and close to precise when well-sized. The myth only errs by extending "correct and usually precise" to "exact and free, always".

10. A Concrete Counterexample

Watch a well-behaved filter deviate under pressure.

Light load — looks perfect. The working set fits the filter; it tracks sharers exactly, every snoop lands on a real holder. The belief looks true.
Hot address set grows. More lines are actively shared than the filter has entries for that set — capacity pressure.
Over-approximation kicks in. To stay correct, the filter widens its tracking — it now indicates caches that might hold lines they don't. The Home issues false-positive snoops; caches answer miss. Wasted traffic (Figure 2).
Capacity forces eviction. To admit a new hot line, the filter evicts an entry — and back-invalidates the corresponding cache line, even though a core was still using it.
The pathology. That core now misses on a line it had — evicted not because its cache was full, but because the filter was. Performance drops, and coherence stayed perfectly correct the whole time.

The counterexample is the same filter: exact under light load, over-approximating and back-invalidating under pressure. "Always perfect" is true of step 1 and false of steps 3–5.

11. What's Actually True

The correct model.

A finite snoop filter approximates the sharer set — it cannot be exact.
It is always correct — never a false negative, never a coherence break.
It over-approximates to stay safe — causing false-positive snoops.
It back-invalidates under capacity pressure — a filter eviction forces a cache eviction.
Correct is not precise — perfect coherence, imperfect (but well-approximated) precision.

12. Why The Distinction Matters

Believing "always perfect" has concrete costs.

You under-budget snoop traffic. Assuming zero false positives leaves the SNP channel undersized for the real over-approximation load (Chapter 21.4).
You miss the back-invalidation pathology. A core losing a hot line to a filter eviction looks like a cache problem — but the filter is the cause (Chapter 21.5).
You mis-size the filter. Not seeing that capacity drives false positives and back-invalidations, you under-provision the filter and pay in performance (Chapter 15.5).
You mis-model performance. Treating the directory as an exact oracle hides a real traffic and eviction term from your estimates (Chapter 21.4).

13. Design Implications

What to do once the filter's finiteness is respected.

Size the filter to the working set — enough coverage to keep false positives and back-invalidations rare (Chapter 15.5).
Budget false-positive snoop traffic — the SNP channel carries more than the true-sharer minimum.
Watch for back-invalidation pathologies — a hot line lost to filter (not cache) pressure (Chapter 21.5).
Model the directory as approximate in performance analysis — not a free, exact oracle.
Trust it for correctness — the one thing it is perfect at; never a false negative.

14. The Trap

Trap: treating the snoop filter as a free, exact oracle

The damage of "snoop filters are always perfect" is a hidden performance term and a mis-attributed bug. Because a well-sized filter is correct and usually precise, it behaves like an oracle on light and medium load — so the belief survives all the easy testing, and the directory gets modeled as free and exact. Then the real workload puts capacity pressure on the filter — a large, actively-shared working set — and two effects appear that the "perfect" model has no place for. First, false-positive snoops: the filter over-approximates to stay correct, so the SNP channel carries snoops to caches that don't hold the line, and if you budgeted for zero of these, the channel is undersized and becomes a bottleneck (Chapter 21.4). Second, the back-invalidation pathology: a core loses a hot, still-useful line — not because its cache filled, but because the filter ran out of entries and had to evict it to stay safe — so the core suddenly misses on data it had, and the engineer, holding the "perfect filter" model, debugs the cache and the workload and finds nothing, because the cause is the filter's capacity, an entirely different structure (Chapter 21.5). Both effects are invisible to correctness — coherence is flawless throughout — and visible only in performance, which is exactly why the "perfect" belief lets them hide.

The fix: hold two properties apart. The filter is perfect for correctness — trust it, no false negatives, ever. It is finite for precision — size it to the working set, budget false-positive snoop traffic, and watch for back-invalidation of hot lines under capacity pressure. Model the directory as a conservative approximation, not a free oracle.

The directory knows exactly who holds each line. Approximately — a finite filter over-approximates under pressure.
A snoop to a cache that misses is a bug. No — a false-positive snoop is correct filter behavior, just imprecise.
Back-invalidations mean the cache is full. No — the filter may be full, forcing a cache eviction (the pathology).
A bigger filter is wasted area. No — filter capacity directly cuts false positives and back-invalidations (Chapter 15.5).
Correct means precise. No — the filter is perfectly correct and only approximately precise.

16. Answering It In An Interview

If asked "is a snoop filter perfect?" — the strong answer:

Split correct from precise. "It's perfect for correctness — never a false negative, so coherence never breaks. It is not precise — it's finite."
Give over-approximation. "To stay safe it over-approximates, causing false-positive snoops to caches that don't hold the line."
Give back-invalidation. "Under capacity pressure it evicts an entry and back-invalidates the cached line — the filter, not the cache, forcing an eviction."
State the trade. "So a finite filter trades a little extra snoop traffic and some back-invalidations for bounded storage — correct, not free."

That splits correctness from precision, names both effects, and states the trade — reasoning, not recital (Chapter 21.6).

17. Key Takeaways

A finite snoop filter approximates the sharer set — it cannot be exact.
It is perfect for correctness — never a false negative, never a coherence break.
It over-approximates to stay safe — causing false-positive snoops.
It back-invalidates under capacity pressure — a filter eviction forces a cache eviction.
Correct is not precise — trust it for coherence, budget for its imprecision.
The trap: treating it as a free, exact oracle — hiding snoop traffic and the back-invalidation pathology.

18. Quick Revision

"Snoop Filters Are Always Perfect" — refuted. A snoop filter is the finite structure that lets a directory snoop only the caches holding a line — and being finite, it can only approximate the true sharer set (an exact filter would need unbounded storage). The one thing it must never do is a false negative — claim "no sharer" when one exists, which would leave a stale copy and break coherence — so it is built conservative, always erring toward too many sharers, and it pays for that safety twice. Over-approximation → false-positive snoops: it tells the Home a cache might hold a line it does not, so the Home snoops it and gets a miss — real fabric traffic and latency spent on nothing. Capacity pressure → back-invalidation: to safely drop a filter entry it must force that line out of the caches too, so the filter — not the cache — evicts a possibly still-useful line, and a core then misses on data it had. The kernel of truth: the filter is always correct (never breaks coherence) and a well-sized one is nearly precise — which is why it feels perfect; the myth only fuses correct with precise/free. The trap is modeling it as a free, exact oracle: under-budgeting false-positive snoop traffic (SNP channel bottlenecks under pressure) and missing the back-invalidation pathology (a hot line lost to filter capacity, mis-debugged as a cache problem) — both invisible to correctness, visible only in performance. Hold the two apart: perfect for correctness, finite for precision — size the filter to the working set, budget its imprecision, and trust it never to miss a sharer. This closes the CHI misconceptions — and the track.

Coming Next

The CHI track is complete. From the first "why coherence exists" through the architecture, transactions, ordering, deadlock, scalability, verification, debugging, the real-world case studies, the design-review checklists, and now the misconceptions engineers carry — you have the full picture. The through-line of every chapter, and of this last one especially, is the same: reason from mechanisms, not from slogans. A snoop filter is "perfect" only if you never ask how it is built; every myth in this module dissolves the moment you trace the actual mechanism — layers and flits, targeted snoops, per-location coherence, permission-versus-data, node types, finite tables. Take that habit into your own designs and interviews: when someone states a CHI "fact," ask why, and what if — the same questions this track taught you to answer. Revisit the design-review checklists (Module 21) when you build, and the interview checklist (Chapter 21.6) before you walk in. That is the whole of AMBA CHI, end to end.