Andy Glew's comp-arch.net wiki, http://semipublic.comp-arch.net

If you are reading this elsewhere, e.g. at site waboba.info, it is an unauthorized copy, and probably a malware site.
comp-arch.net wiki on hold from October 17, 2011

From CompArch

Exactly what flavour of write-through?

Intel P6 had an “invalidate as you write-through” write-through (WT) protocol. You could write to a line that you did not own, but as you propagated through the memory subsystem you would invalidate all clean cache lines you encountered, and/or force eviction of dirty lines.

Note that if there is no write-back (WB) you only ever invalidate. But if you can ever have memory type aliasing, with the same memory locations WT in one place and time and WB at another, you must decide what to do.

BS: merge write-through data with dirty data to be copied back.
• if the write through still continues, you probably want a dirty byte bitmask associated with this transaction.
• however, in some cases you may merge the write-through into the dirty line when encountered.
It all depends on what semantics you define for memory type aliasing. And whether you are using WT for reliability (in case you want to write out to a sufficiently reliable layer) or as a performance hint (in which case merging may be okay).

IBM mainframes historically have an “invalidate before you write” write-through protocol. Before a write-through is allowed to happen, they ensure that all other copies of the cache line, wherever they are, have been invalidated and/or written back.

i.e. “invalidate before you write” essentially creates an ownership based protocol for WT, just like WB.

Intel has started doing “invalidate before you write” with QPI.

Motivations for “invalidate before you write”:

• avoids the complexity of having to force eviction of dirty lines as they are encountered with “invalidate as you are writing”
  • some systems, e.g. AMD, have tried to avoid this by fiat, saying “You aren’t allowed to have the same address both WT (or uncached (UC)) and WB”
• Intel learned the hard way that this did not make customers happy
• makes it easy to build a sequentially consistent memory model.
  • I suspect this is the big motivation for IBM mainframes having it.
  • “Invalidate as you write” is fundamentally incompatible with strong ordering.

Cons:

• “invalidate before you write” amounts to implementing ownership for WT and UC, just like WB
  • you start talking about having “ownership directories” for uncached memory
• optimizations like the memcopy stuff we were just talking about – avoiding unnecessary read-for-ownership (RFO) – are affected
  • you can’t eliminate the RFO
  • although you can make the RFO an address only transaction, not carrying data

“Invalidate before you write” is overall lower performance than “invalidate as you write”. But it is arguably simpler in the presence of memory type aliasing, and simpler for strong memory ordering.