1

I understand that with MSI, if we have a piece of memory in shared state, even if no one else uses it, we would have to broadcast that we are moving to modified. This is a problem that MESI fixes.

However, when we do use MESI, when moving from invalid to exclusive, we need to broadcast that we want to read this, and wait if there are not HIT reponses. How is this any better?

Maoepr3n
  • 13
  • 3
  • Your "without MESI" case is using MSI? Without *anything* you don't even have coherence and can't really build a useful SMP system. – Peter Cordes Dec 03 '19 at 13:36
  • If your line was originally "Invalid", that's a cache miss regardless of any coherency protocol. You need to read it from somewhere else. (Unless you're doing a full line write in which case yes you can broadcast an invalidate instead of an RFO.) – Peter Cordes Dec 03 '19 at 13:39
  • @PeterCordes Yes, I meant MSI. And yeah, i need to read it (from memory) and then we do the things I said. But it seems like I don't save myself any broadcasting, I just do it when getting my stuff instead of doing it when I move from shared to modified. – Maoepr3n Dec 03 '19 at 13:43

1 Answers1

4

I need to read it (from memory) and then we do the things I said. But it seems like I don't save myself any broadcasting, I just do it when getting my stuff instead of doing it when I move from shared to modified.

Consider the case where you load first, then store. With MSI you'd read into Shared, then need to go off-core again to get exclusive ownership before committing a store.

With MESI you read into Exclusive state for the pure load, and then flipping to Modified is local; no off-core communication.

Turns out this is the example Wikipedia gives in https://en.wikipedia.org/wiki/MESI_protocol#Advantages_of_MESI_over_MSI

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
  • I see, thanks! So the hit r reponses we get in MESI are rare enough to compensate for the one request we have to send less? – Maoepr3n Dec 03 '19 at 14:06
  • 2
    @Maoepr3n Not necessarily, in the traditional MESI, the load transaction by itself doesn't determine whether the line will be fetched in the E or S state. It's the response message that tells the cache whether to place the line in the E or S state. So the E state is used *opportunistically*. You can extend MESI with a transaction that requires a line in E. For example, x86 offers the `PREFETCHW` instruction, which is implemented by adding a load-exclusive transaction. This forces the line to be in the E state regardless of its state in the caches of other agents in the coherence domain. – Hadi Brais Dec 03 '19 at 16:45
  • 2
    The E state is also used *optimistically* in the sense that if a load was not followed by a store (the scenario MESI optimizes) and if other cores want to load the line, this can lead to additional traffic between the cores compared to MSI (to tell the core that has it in E to transition to S). If this happens too many times, it may potentially result in higher power consumption and performance degradation (due to contention on the interconnect and cache access ports, depending on the exact design). – Hadi Brais Dec 03 '19 at 16:45