Yes in an inclusive LLC with presence bits in each tag: a tag miss proves no private copy. No in an exclusive or NINE LLC: H needs a separate snoop filter, and that filter's evictions back-invalidate (Part 5).
These examples use the Part 9 LLC model: the LLC sits at H, a PutM writes the LLC line, and memory is written only when the LLC evicts a dirty line. In the inclusive case the directory entry is the presence vector stored beside the LLC tag, so one lookup gives the data location and the holders. gem5's MESI_Two_Level protocol is built this way: its shared L2 is inclusive of the L1s and keeps the directory state in the L2 block (gem5 documentation).
Record | What it holds | What its presence establishes | What it cannot establish alone |
|---|---|---|---|
LLC data tag | tag + LLC value + dirty bit; the value may be older than a private M copy | The LLC has a copy, and whether it is newer than memory | That no private cache holds a newer value |
Presence bits in an inclusive LLC tag | One bit per private cache | Which private caches may hold X. A tag miss proves none does | Whether a recorded holder is clean or dirty (E may have become M silently) |
Separate snoop filter entry (exclusive, NINE) | Tag + holder set, no data | Which private caches may hold X, independent of LLC residency | Where the data is: the LLC may or may not have X |
Pending transaction record | An admitted unfinished request for X | Conflicting requests must wait | The requester's final permission |
Case | C0 state / value | C1 state / value | H directory | LLC: tag / value / dirty | Memory | Newest data |
|---|---|---|---|---|---|---|
(a) Inclusive | M / 1 | I / - | exclusive(C0) (presence bits {C0} in LLC tag) | X / 0 / clean | 0 | C0: 1 |
(b) Exclusive with snoop filter | M / 1 | I / - | exclusive(C0) (snoop filter) | no tag | 0 | C0: 1 |
(c) NINE after C0's PutM | I / - | I / - | U (snoop filter) | X / 1 / dirty | 0 | LLC: 1 |
Now C1 sends GetS(X). In (a) the LLC tag hits and its presence bits name C0, so H forwards to C0 rather than supplying the stale 0. In (b) the LLC misses, but the filter names C0, so H forwards to C0. In (c) the filter records no holder and the LLC hits with dirty 1, so the LLC supplies 1 and memory stays 0. The failure without the filter: if H in (b) took the LLC miss as proof of absence and read memory, C1 would get 0 while C0 holds 1.
A snoop filter entry costs tag and holder bits with no data. Reclaiming it when its set is full back-invalidates the holders exactly as an inclusive LLC eviction does, so moving to exclusive or NINE moves back-invalidation from the LLC to the filter rather than removing it.
No. In case (b) the filter entry is the only record that C0 holds M / 1. Reclaiming it requires a back-invalidation that recovers the data.