MESIF protocol

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 X Red X Red X Green tick Red X
 E  Red X Red X Red X Green tick Red X
 S  Red X Red X Green tick Green tick Green tick
 I  Green tick Green tick Green tick Green tick Green tick
 F  Red X Red X Green tick Green tick Red 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 another cache.

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 use cache-to-cache transfers to efficiently transfer data between caches (instead of expecting information from the main memory), there is a subtle difference behind the intent of the two states.

The F state in the MESIF protocol is an optimization to the MESI protocol where a read request for data in the "shared" state is serviced by one of the sharers of the data 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.

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. Retrieved 2014-03-21.
  3. ↑ US 6922756, Hum, Herbert H. J. & James R. Goodman, "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 - version of the 10/26/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.