MESI protocol

• The most popular invalidation-based protocol e.g., appears in Intel Xeon MP
• Why need E state?
  • The MSI protocol requires two transactions to go from I to M even if there is no intervening requests for the line: BusRd followed by BusUpgr
  • We can save one transaction by having memory controller respond to the first BusRd with E state if there is no other sharer in the system
  • How to know if there is no other sharer? Needs a dedicated control wire that gets asserted by a sharer (wired OR)
  • Processor can write to a line in E state silently and take it to M state

State transition

• If a cache line is in M state definitely the processor with the line is responsible for flushing it on the next BusRd or BusRdX transaction
• If a line is not in M state who is responsible?
  • Memory or other caches in S or E state?
  • Original Illinois MESI protocol assumed cache-to-cache transfer i.e. any processor in E or S state is responsible for flushing the line
  • However, it requires some expensive hardware, namely, if multiple processors are caching the line in S state who flushes it? Also, memory needs to wait to know if it should source the line
  • Without cache-to-cache sharing memory always sources the line unless it is in M state

• Take the following example
  • P0 reads x, P0 writes x, P1 reads x, P1 writes x, …

    P0 generates BusRd, memory provides line, P0 puts line in cache in E state

    P0 does write silently, goes to M state

    P1 generates BusRd, P0 provides line, P1 puts line in cache in S state, P0 transitions to S state
    Rest is identical to MSI

  • Consider this example: P0 reads x, P1 reads x, …

    P0 generates BusRd, memory provides line, P0 puts line in cache in E state

    P1 generates BusRd, memory provides line, P1 puts line in cache in S state, P0 transitions to S state (no cache-to-cache sharing)
    Rest is same as MSI