MOESI Protocol

• State transitions pertaining to O state
  • I to O: not possible (or maybe; see below)
  • E to O or S to O: not possible
  • M to O: on a BusRd /Flush (but no memory writeback )
  • O to I: on CacheEvict / BusWB or { BusRdX,BusUpgr }/Flush
  • O to S: not possible (or maybe; next slide)
  • O to E: not possible (or maybe if silent eviction not allowed) '
  • O to M: on PrWr / BusUpgr
• At most one cache can have a line in O state at any point in time
• Two main design choices for MOESI
  • Consider the example P0 reads x, P0 writes x, P1 reads x, P2 reads x, P3 reads x, …
  • When P1 launches BusRd , P0 sources the line and now the protocol has two options: 1. The line in P0 goes to O and the line in P1 is filled in state S; 2. The line in P0 goes to S and the line in P1 is filled in state O i.e. P1 inherits ownership from P0
• For bus-based SMPs the two choices will yield roughly the same performance
• For DSM multiprocessors we will revisit this issue if time permits
• According to the second choice, when P2 generates a BusRd request, P1 sources the line and transitions from O to S; P2 becomes the new owner

MOSI Protocol

• Some SMPs do not support the E state
  • In many cases it is not helpful, only complicates the protocol
  • MOSI allows a compact state encoding in 2 bits
  • Sun WildFire uses MOSI protocol