The MESIF protocol is a cache coherency and memory coherence protocol developed by Intel for cache coherent non-uniform memory architectures.[1] The protocol consists of five states, Modified (M), Exclusive (E), Shared (S), Invalid (I) and Forward (F).[2]

The M, E, S and I states are the same as in the MESI protocol. The F state is a specialized form of the S state, and indicates that a cache should act as a designated responder for any requests for the given line. The protocol ensures that, if any cache holds a line in the S state, at most one (other) cache holds it in the F state.

In a system of caches employing the MESI protocol, a cache line request that is received by multiple caches holding a line in the S state will be serviced inefficiently. It may either be satisfied from (slow) main memory, or all the sharing caches could respond, bombarding the requestor with redundant responses. In a system of caches employing the MESIF protocol, a cache line request will be responded to only by the cache holding the line in the F state.[3] This allows the requestor to receive a copy at cache-to-cache speeds, while allowing the use of as few multicast packets as the network topology will allow.

 M  E  S  I  F 
 M  Red XRed XRed XGreen tickRed X
 E  Red XRed XRed XGreen tickRed X
 S  Red XRed XGreen tickGreen tickGreen tick
 I  Green tickGreen tickGreen tickGreen tickGreen tick
 F  Red XRed XGreen tickGreen tickRed X

Because a cache may unilaterally discard (invalidate) a line in the S or F states, it is possible that no cache has a copy in the F state, even though copies in the S state exist. In this case, a request for the line is satisfied (less efficiently, but still correctly) from main memory. To minimize the chance of the F line being discarded due to lack of interest, the most recent requestor of a line is assigned the F state; when a cache in the F state responds, it gives up the F state to the new cache.

Thus, the main difference from the MESI protocol is that a request for a copy of the cache line for read always enters the cache in the F state. The only way to enter the S state is to satisfy a read request from main memory.

For any given pair of caches, the permitted states of a given cache line are listed in the table on the right. The order in which the states are listed has no significance other than to make the acronym MESIF pronounceable.

There are other techniques for satisfying read requests from shared caches while suppressing redundant replies, but having only a single designated cache respond makes it easier to invalidate all copies when necessary to transition to the Exclusive state.

Comparison to MOESI protocol

The F state in this protocol should not be confused with the "Owner" O state in the MOESI protocol. While both states identify one cache out of a set of sharers to efficiently transfer data using direct cache-to-cache transfers (instead of expecting information from the main memory), there is a difference behind the intent of the two states.

  • A cache line in the F state is clean and may be discarded at any time without notice.
  • A cache line in the O state is dirty and must be written back to memory before being discarded.

The F state in the MESIF protocol is simply a way to choose one of the sharers of a clean cache line to respond to a read request for data using a direct cache-to-cache transfer instead of waiting for the data to come from the main memory. This optimization makes sense in architectures where the cache-to-cache latency is much smaller in comparison to the latency of accessing the main memory. A key point to be noted here is that, similar to the MESI protocol, when data is in the shared state (with one of the caches in the F state) the data is clean.

The O state in the MOESI protocol is an optimization to the MESI protocol where the requirement of the shared data to be clean is relaxed. In other words, caches can share data which are dirty as long as one of the sharers takes the responsibility of owning the data. Requests for the shared data now will be satisfied by the owner. This optimization allows delaying the writeback of data by allowing sharing of dirty data.[4] The key difference in the MOESI protocol is that, unlike the MESIF protocol, the Owned state is not clean.

It is possible to construct a MOESIF protocol.

See also

References

  1. ↑ David Kanter (2007-08-28), "The Common System Interface: Intel's Future Interconnect", Real World Tech: 5, retrieved 2012-08-12
  2. ↑ Michael E. Thomadakis (2011-03-17). "The Architecture of the Nehalem Processor and Nehalem-EP SMP Platforms" (PDF). Texas A&M University. p. 30–34. Archived from the original (PDF) on 2014-08-11. Retrieved 2014-03-21.
  3. ↑ US 6922756, Hum, Herbert H. J. & Goodman, James R., "Forward state for use in cache coherency in a multiprocessor system", issued 2005-07-26, assigned to Intel Corporation
  4. ↑ Hennessy, J.; Patterson, D. Computer Architecture: A Quantitative Approach (fifth ed.). p. 362.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.