The MESI protocol

The MESI protocol, which is named after the four states it includes, was first pre- sented in 1984 by Papamarcos[27] in the University of Illinois2_{. Due to its simplicity}

and capability of being used in systems with many cores with good performance, it is usually taken as example for coherence protocols in the literature.

The four states are enough to describe the status of the cache blocks at any time. The Invalid state guarantees no presence of the block in the cache, states Exclusive and Modified guarantee exclusive ownership of the block, and finally, the Shared state guarantees presence but not exclusivity of the block, that is, the block may or may not be the only copy among all the caches. Table 2.1 describes each one of the states.

Table 2.1: Description of states in the MESI protocol.

State Description

I Invalid: The block is not present in the cache.

S Shared: The cache entry is potentially shared with one or more

caches. The block is clean; it is consistent with the version stored in the directory.

E Exclusive: The cache entry is only present in the local cache.

The block is clean; it is consistent with the version stored in the directory.

M Modified:The cache entry is only present in the local cache and it

is dirty. Write-back when the block is evicted from the local cache or shared with other caches.

On the other hand, a coherence protocol must react to events that can be origi- nated by a special condition in one of the elements of the cache hierarchy. Depending on the origin of the events, they can be classified as: local reference (due to local CPU’s request), remote reference (due to other cache’s request) or local capacity eviction (generated inside the local cache). Table 2.2 shows a description of all the events defined in the protocol.

As every FSM, the caches are not just passive entities that receive events and move from one state to another, they are active elements of the protocol that answer to the events depending on the state they are in. A description of the actions they do is shown in table 2.3.

It is worth noting the relationship between the actions done by one cache and the events received from others. For example, if one cache have a read miss, it will issue a GETS request to the interconnection network and other caches will receive that request as a Fwd_GETS (network read) event.

The last missing thing to complete the description of the protocol is the definition of the transitions between states. Figure 2.3 shows the state diagram of the protocol,

Table 2.2: Description of events in the MESI protocol.

Local reference

Event Description

Ifetch Local CPU issued an Instruction Fetch request to the cache.

Load Local CPU issued a Load request to the cache. Store Local CPU issued a Store request to the cache.

Remote reference

Event Description

Fwd_GET_INSTR Instruction Fetch miss in other cache, local cache must share the block.

Fwd_GETS Data Load miss in other cache, local cache must share the block.

Fwd_GETX Store miss in other cache, local cache must invalidate its copy and send the block to the requester.

INV Either the directory or other cache request the local cache to invalidate its copy of the block.

Local capacity

Event Description

L1_Replacement There is no enough room in the local cache to allocate a new cache block, it must evict one.

Table 2.3: Description of actions in the MESI protocol.

Action Description

GET_INSTR Local cache requests an instruction to the directory.

GETS Local cache requests a data block without intent to modify it, probably because of a load miss.

GETX Local cache requests a data block with intent to modify it, this message implies the invalidation of other copies.

PUTX Local cache writes the data back to the shared memory due to eviction of the block.

the arrows represent the transitions and the labels next to each arrow show the events that can trigger the transition.

I S M E Lo ad L o ad In v L 1_ R e p l Stor e S to re Store Fwd_ GETS F w d _ G E T X Fwd_GETS Inv L1_Repl Fwd_ GETX Inv L1_Repl Fw d_G ET_X Load Load Store Load

Figure 2.3: State diagram of the MESI protocol.

action of the caches in the protocol, lets consider the following example depicted in figure 2.4. Inside figure 2.4, states in red represent the current state of the cache blocks at a given time. Suppose a two-core system with two private caches and a block that is not present in either cache at time 0. At the following time step cache0 receives the Load event from the local CPU, it allocates the requested block, moves to E sends the data to the CPU. Then, at time=2, the CPU performs a store and the cache changes its state to M. When cache1 receives a Load from its local CPU at time=3, it asks cache0 to share the block and both caches change their states to S. Next, the CPU attached to cache1 does a write to the block which invalidates cache0’s copy and makes cache1 move to M. Finally, at time=5 cache0 receives a store request, hence it makes cache1 invalidate its copy and send the block to cache0, which moves to M and performs the store.