Directory protocols directory protocol Cache controllers unicast requests to the block's home memory controller, whose directory tracks owner/sharer state and responds or forwards to the owner; scalable but adds indirection. defined in Chapter 6 — open in glossary were born to fix snooping’s scalability problem: no more totally ordered broadcast network, no more every-controller-snoops-every-request. The price is a level of indirection. This chapter builds a complete MSI directory protocol (§8.2), adds E (§8.3) and O (§8.4), then turns practical: representing directory state (§8.5), organizing the directory (§8.6), performance and scalability (§8.7), four commercial case studies (§8.8), and the outlook (§8.9). (The book’s note: §8.3–8.7 are skimmable.)
The key innovation
A directory maintains a global view of each block’s coherence state: which caches hold it, and in what states. A cache controller unicasts its request to the directory (no broadcast!); the directory looks up the block and either responds itself or forwards the request — e.g., a Fwd-GetS forwarded request (fwd-gets/fwd-getm) A request the directory redirects to the owner cache, which then responds directly to the original requestor — the middle hop of a three-hop transaction. defined in Chapter 8 — open in glossary — to the owning cache, which responds directly to the requestor.
Directory transactions: two hops when the directory owns the block, three when a cache does — and explicit acknowledgments where snooping had implicit ones.
Some protocols even add a fourth step, when responses indirect through the directory or the requestor notifies the directory on completion (both appear in §8.8’s case studies). Snooping, for contrast, is always two steps: broadcast request, unicast response.
Ordered at the directory
Like snooping, a directory protocol must define when transactions are ordered. The answer: at the directory. Racing requests are ordered by whichever the network delivers first; the loser may be (a) processed immediately after the winner, (b) held at the directory until the winner completes, or (c) negatively acknowledged ( NACKed nack Negative acknowledgment forcing a requestor to re-issue its request; risks livelock (section 9.3.2), so this book's protocols avoid it (the SGI Origin's Upgrade race uses one). defined in Chapter 8 — open in glossary ) and forced to re-issue. This book’s protocols use (a) and (b) only — NACKs invite livelock, as §9.3.2 will show (the SGI Origin’s Upgrade race in §8.8 is a real NACK sighting).
No total order — so, explicit acknowledgments
The fundamental trade
Scalability versus indirection. A directory protocol needs no ordered broadcast and no snoop-everything bandwidth — that’s why it scales — but some transactions take three hops instead of two. The rest of this chapter is, in one sense, a study of managing that trade.
Check yourself
1.What is the key innovation of directory protocols?
2.How many steps does a directory coherence transaction take?
3.Where are directory-protocol transactions ordered, and what can happen to the loser of a race?
4.Why does a directory-protocol GetM need explicit Inv-Ack messages when snooping needed none?