3
\$\begingroup\$

As I understand, those two protocols add an extra state to identify which cache should respond to a miss request from another cache for a particular cache-line.

But, in the MESI protocol, only one cache can have a cache-line 'A' in the modified state. The other caches can have 'A' in the invalid state or not at all in the cache.

Instead of adding an extra state, can we not just make the cache which has the requested cache-line in the modified state respond to a miss request generated by another cache for said cache-line?

Additionally, is there another motive for introducing the MOESI/MESIF protocols?

\$\endgroup\$
3
  • \$\begingroup\$ It looks like you did not realize that M state is an exclusive state so all other caches must either have the block in the I state or not have a tag match. \$\endgroup\$ Dec 10 '13 at 16:48
  • \$\begingroup\$ @PaulA.Clayton, Ah yes. Thanks for pointing that out. \$\endgroup\$ Dec 11 '13 at 0:35
  • \$\begingroup\$ The wikipedia articles do a nice job of explaining the differences, and the motivation for having them: en.wikipedia.org/wiki/MESIF_protocol and en.wikipedia.org/wiki/MOESI_protocol. The MESIF article even has a section contrasting with MOESI. \$\endgroup\$ May 25 '17 at 21:38
4
\$\begingroup\$

MOESI allows more than one cache to have a copy of a block that is dirty (relative to main memory). MOESI provides all four states one would expect for the two binary traits present-in-only-one-cache/possibly-present-in-multiple-caches (M,E/O,S) and needs-to-be-written-to-memory-on-eviction/can-be-invalidated-without-writeback (M,O/E,S). (The invalid state excludes all four of those states.)

Under traditional use of MESI, if a cache miss hits a Modified block in another cache, the cache block would be written to memory, marked as Invalid in the providing cache, and marked as Exclusive in the requesting cache. Obviously, the M state could be transferred to the requesting cache (avoiding the writeback to memory), but the providing cache would still need to invalidate the cache block so multiple caches could not hold the block at the same time.

Avoiding writebacks can reduce the use of main memory bandwidth. (Alternatively, more flexible scheduling of writebacks which can distribute spurts of memory activity or exploit the lower cost of multiple accesses within the same DRAM row.)

The addition of the Forward state is intended to reduce the amount of coherence traffic by having at most one cache respond with data. (The Owned state provides a similar advantage but only if the "shared" block is dirty relative to memory.) On a cache miss, a request can be broadcast and any cache with the block in M, E, or F state can provide the data. With MESI, every cache with the block in Shared state would respond with the data.

(If the interconnect between caches was sufficiently loaded that there was buffering delay, this delay might be sufficient to check if the cache[s] at a network node had a block in a single-provider state [M, E, F], allowing a read request broadcast not to be sent further. Other, more practical optimizations are likely possible. "MESIF: A Two-Hop Cache Coherency Protocol for Point-to-Point Interconnects" might provide more information. [I have not read that paper, and my understanding of MESIF is even less than my understanding of MOESI.])

\$\endgroup\$
4
  • \$\begingroup\$ Exactly! So my point is, why can we not just modify the MESI protocol such that when a cache A, upon detecting a bus read request, checks if it has the requested cache-line in the modified state. If not, ignore. If yes, respond. Wouldn't this eliminate the need for an extra state? \$\endgroup\$ Dec 9 '13 at 16:13
  • \$\begingroup\$ @AnishRam Are you asking why (in MESI) E and S state respond with data rather than having the data taken from main memory? In small snoop-based systems, a remote cache tends to have lower latency than main memory. For earlier single level cache systems, reading from memory could have higher performance than disrupting the providing core; for larger, directory-based systems sourcing from memory would often be a good choice. MESIF is only for snoop-based systems; MOESI would still save writeback bandwidth but complicates a directory-based system. \$\endgroup\$ Dec 10 '13 at 14:39
  • \$\begingroup\$ No. What I'm asking is, instead of adding an extra state to determine which cache should service the miss (rather than all responding), why not modify the MESI protocol in such a way so that the cache having the requested cache-line in the modified state responds? Modified state implies ownership to me. \$\endgroup\$ Dec 10 '13 at 15:27
  • 1
    \$\begingroup\$ @AnishRam M state is exclusive. If any cache has a block in M (or E) state, no other cache can have the block in a valid state. Typically, M state would uniquely respond with data, writeback to memory, and update to itself S. F and O states are specializations/extensions of S; if a block is in S (F or O) state, no cache can have it in M (or E) state. S allows multiple caches simultaneous read access to a block. Even in simple producer-consumer communication, S state allows the producer to avoid read-for-ownership (sending an invalidate message rather than retrieve data and invalidate). \$\endgroup\$ Dec 10 '13 at 16:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.