A cache that is about to lose power holds two kinds of obligation: dirty data that exists nowhere else, and permissions that H has recorded and will act on. Turning the supply off breaks both at once: the data vanishes, and H's next Inv or Fwd goes to a controller that can never reply. This topic turns power-down into a coherence transaction with a defined completion, then looks at retention and at the race between powering down and an incoming forward.
Course-model extension for this topic: C0's cache can be powered down. A powered-off or retained controller answers nothing, not even 'I do not have it'. The topic adds four course-defined messages, Leave, Leave-Ack, Join and Join-Ack, for leaving and rejoining the coherence domain; they are not messages of any named protocol. Everything else follows the course model.
Lesson | After it you can... |
|---|---|
List what must be cleaned, invalidated and completed before a cache may lose power, and name the completion predicate. | |
Order stop, drain, flush, leave and power-off, and the rejoin steps, and say what breaks if two steps swap. | |
Explain why kept bits are not a coherent copy, and choose between power-off, retention with flush and wake-on-snoop. | |
Trace a Fwd-GetM crossing C0's PutM during power-down, and show which shortcuts lose data or hang. |
Read in order. The lessons build on Dirty Writeback, Writeback Buffers and Eviction Versus Intervention.
Not while H still records it as a sharer. The data is safe, because memory is current, but the next GetM from C1 makes H send Inv to C0 and wait for an Inv-Ack that a powered-off cache cannot send. C0 must first send PutS for each line (or a bulk Leave) and wait for the acknowledgements.