Cache cohernce with multi-processor

Cache cohernce with multi-processor

Author: BNN
Reposted from: CPU and compiler of linuxforum

After writing an article about cache coherence, I found that there was a good article about bnn2 years ago. I knew it was not so troublesome to write it myself :)

Recently work with Dual CPU kernel part. For Dual CPU, or we say, multi-processor, the big challenge part for a kernel is how to handle the cache coherence.

Conceptually, two choices -- write invalidate and write update.

We will talk about write invalidate today.

Typically, there are two protocols falling into the write invalidate Protocol, namely, the write-through write invalidate protocol and the write once (or write-back write invalidate protocol ). note that the well-known MESI protocol is derived from the write once. that's why we will focus on the write once here.
--------------------------
Write once:

Write Once protocol is to offset the specified comings of write-through write-invalidate protocol, which will introduce extra bus traffic onto the system bus.

Write Once works basically as follows:

(Assume
* The hardware Snoop enabled over the shared system bus.
* The cache is write back
)
There are four states for write once protocol -- valid, reserved, dirty and invalid.

Initial State:

* When a load miss, the data will be loaded into cache line and the State goes to valid state

// Please note here, write once protocol will promise that your loaded data in memory will be the latest. Why? If at the time you tried to load a cache line, there is an modified copy in another CPU, the Snoop protocol will abort the Load Bus transaction; flush another CPU's data into main memory and then resume the aborted transaction so that the requesting CPU will then get the updated data ....

Now, let's investigate the state machine of write once protocol.

***************
Valid state:
***************

When a load hit, we do nothing. That's right. The cache line is already here. CPU is happy to find the data in the cache.

When a load miss, we will re-start the init procesure to load the latest data into cache line.

When a CPU store hit (a store hit from the current processor), now comes to the key part of write once protocol. when having a write/store behavior, For up (unique processor) system, we all understand that the cache state will go to dirty state and ***** didn't write data back to main memory ****. however, write-once protocol works like this below in order to achieve multiple processor cache coherence.

The stored data will be flushed back to main memory (why? We need a bus transaction over the bus !!!) And then cache state will be moved to reserved state.

This is exactly why this protocol is given the name of "write once" --- write the first time write access to a write-back cache line into main memory *****!!!! So that other processor cache controller will be awared and then invalidate the corresponding cache lines, and thus the whole system will only one copy of the cache line.

After the first time write once, the subsequent write access will only change the state to dirty state and the data will stay in cache line and will not be flushed into main memory, the same case as we see in up write-back approach.

When a snoop stoee hit (we found another CPU is trying to do a store on that cached address), then, with the write-invalidate semantics, we know, the system will then invalidate its own copy in this current processor in order to keep only one legal copy for that cache line. in other words, the State will go to invalid state from valid state. note that, we don't have to do any flush. the reason is simple: In this processor, we didn't do any write yet. so we will only invalidate our own copy in this processor. in the later, if we want to read this participant data, we will have to load it from main memory again.

For valid state, we have other input needed to be considered, like

Snoop load hit
CPU store miss

How CPU will react with these two actions?
I will leave questions to you guys ......

Recently work with Dual CPU kernel part. For Dual CPU, or we say, multi-processor, the big challenge part for a kernel is how to handle the cache coherence.

Conceptually, two choices -- write invalidate and write update.

We will talk about write invalidate today.

Typically, there are two protocols falling into the write invalidate Protocol, namely, the write-through write invalidate protocol and the write once (or write-back write invalidate protocol ). note that the well-known MESI protocol is derived from the write once. that's why we will focus on the write once here.
--------------------------
Write once:

Write Once protocol is to offset the specified comings of write-through write-invalidate protocol, which will introduce extra bus traffic onto the system bus.

Write Once works basically as follows:

(Assume
* The hardware Snoop enabled over the shared system bus.
* The cache is write back
)
There are four states for write once protocol -- valid, reserved, dirty and invalid.

Initial State:

* When a load miss, the data will be loaded into cache line and the State goes to valid state

// Please note here, write once protocol will promise that your loaded data in memory will be the latest. Why? If at the time you tried to load a cache line, there is an modified copy in another CPU, the Snoop protocol will abort the Load Bus transaction; flush another CPU's data into main memory and then resume the aborted transaction so that the requesting CPU will then get the updated data ....

Now, let's investigate the state machine of write once protocol.

***************
Valid state:
***************

When a load hit, we do nothing. That's right. The cache line is already here. CPU is happy to find the data in the cache.

When a load miss, we will re-start the init procesure to load the latest data into cache line.

When a CPU store hit (a store hit from the current processor), now comes to the key part of write once protocol. when having a write/store behavior, For up (unique processor) system, we all understand that the cache state will go to dirty state and ***** didn't write data back to main memory ****. however, write-once protocol works like this below in order to achieve multiple processor cache coherence.

The stored data will be flushed back to main memory (why? We need a bus transaction over the bus !!!) And then cache state will be moved to reserved state.

This is exactly why this protocol is given the name of "write once" --- write the first time write access to a write-back cache line into main memory *****!!!! So that other processor cache controller will be awared and then invalidate the corresponding cache lines, and thus the whole system will only one copy of the cache line.

After the first time write once, the subsequent write access will only change the state to dirty state and the data will stay in cache line and will not be flushed into main memory, the same case as we see in up write-back approach.

When a snoop stoee hit (we found another CPU is trying to do a store on that cached address), then, with the write-invalidate semantics, we know, the system will then invalidate its own copy in this current processor in order to keep only one legal copy for that cache line. in other words, the State will go to invalid state from valid state. note that, we don't have to do any flush. the reason is simple: In this processor, we didn't do any write yet. so we will only invalidate our own copy in this processor. in the later, if we want to read this participant data, we will have to load it from main memory again.

For valid state, we have other input needed to be considered, like

Snoop load hit
CPU store miss

How CPU will react with these two actions?
I will leave questions to you guys ......

----------------
Valid state
----------------

Snoop load hit:
That means that current CPU cache controller **** see ** a bus transaction issued by another device, for instance, another CPU, to access the data that is currentily cached. when this happens, current CPU cache will do nothing but stay the valid state. the reason is simple: another device/CPU will fetch the data from the memory that still holds the latest data.

CPU store Miss:

How/when this situation cocould happen, after a cache line was loaded before? Yeah, you are right. That cache line cocould be ** replaced ** by other datas (remember the LRU algorithm of Cache Management; set associative concepts/mechanic ISMs and so such ).

When a CPU store Miss happens, the data will be written into main memory and also have a copy in the cache (that's the "write allocate" when handling a write Miss ). after that, the cache Snoop protocol will move its state into reserved from the valid. why? That means that a write and more importantly, the first write, has just completed!

--------------
Reserved
--------------

As I said before, the reserved state was introduced to reflect the write once semantics -- the first write will flush data into memory so that other devices/CPUs are able to see/be notified a bus transaction!

For this state, same as valid state, its input coshould vary as follows:

* CPU load hit
Simply feed the data back to CPU and keep the state stay.

* CPU write hit
Since we are using wt (write back) for the cache lines, then we will change our state to dirty. in other words, we will not flush data into memory, in contrast with the wt (write through) approach.

* CPU load miss

System will simply load the data from main memory and keep a copy in the cache (if it is not-read through). and reset the system as valid state.

* CPU write Miss

This cache line got replaced some time after it was loaded into cache. system will simply write the data back to main memory and then keep the latest copy in the cache and set the State still as reserved.

* Snoop load hit

We ** see ** another device is to read the cached data. here we don't have to do any cache flush/invalidating behavior. what need to do is to change the cache coherent Protocol state to valid. question: What wowould happen if we stay reserved state? For example, if there is a coming CPU store hit? :-)

* Snoop write hit

We ** see ** a write access issued by another device/CPU. we will invalidate our own cache, which will then become stale and move our state to invalid. the reason why we don't have to involve in any flushing is simple: our local cache data value is the same as the one in main memory. thus, the only thing we need to do is to invalidate our private copy.