1.思考和質疑

在一個大架構大系統中，有哪些一致性需要維護？我們先看如下一張架構圖。

然后請思考：

(1)、core0中的L1和L2 cache有一致性的要求嗎？緩存和替換策略是怎樣的？

(2)、core0 cache 和 core1 cache的一致性是誰來維護？遵從MESI協議嗎？

(3)、core0 cache 和 core4 cache的是怎么維護一致性的呢？

(4)、custer0 L3 cache 和 cluster1 L3 cache的一致性是誰來維護？遵從什么協議嗎？

(5)、custer0 L3 cache 和 GPU的L2一致性呢？遵從什么協議？

(6)、custer0 L3 cache 和 其它的I/O deviceMaster一致性呢？遵從什么協議？

(7)、DSU、ACE、CHI、CCI、CMN的概念？

網上的好多篇博文，一提Cache的多核一致性就必然提到 MESI、MOESI ，然后就開始講 MESI、MOESI維護性原理？試問一下，您是真的不理解MESI嗎？您真的需要學習MESI？你不理解的是架構吧，而不是學什么協議.既然要學習MESI，那么這里也繼續提出一些問題：

(1)、ARM架構中真的使用MESI了嗎？或者是哪一級cache使用了，哪一級cache沒有使用？

(2)、MESI是一個協議？是誰來維護的？總得有個硬件實現這個協議吧，是在ARM Core實現？DSU實現？

(3)、MESI的四種狀態，分別記錄在哪里的？

(4)、arm現在主流的core，到底使用的是MESI，還是MOESI？

2.怎樣去維護多核多系統緩存的一致性

有三種機制可以保持一致性：

禁用緩存是最簡單的機制，但可能會顯著降低 CPU 性能。為了獲得最高性能，處理器通過管道以高頻率運行，并從提供極低延遲的緩存中運行。緩存多次訪問的數據可顯著提高性能并降低 DRAM 訪問和功耗。將數據標記為“非緩存”可能會影響性能和功耗。

軟件管理的一致性是數據共享問題的傳統解決方案。在這里，軟件（通常是設備驅動程序）必須清除或刷新緩存中的臟數據，并使舊數據無效，以便與系統中的其他處理器或主設備共享。這需要處理器周期、總線帶寬和功率。

硬件管理的一致性提供了一種簡化軟件的替代方案。使用此解決方案，任何標記為“共享”的緩存數據將始終自動更新。該共享域中的所有處理器和總線主控器看到的值完全相同。

然而，我們在ARM架構中，默認使用的卻是第三種 硬件管理的一致性, 意思就是：做為一名軟件工程師，我們啥也不用管了，有人幫我們干活，雖然如此，但我們還是希望理解下硬件原理。

再講原理之前，我們先補充一個場景:假設在某一操作系統中運行了一個線程，該線程不停著操作0x4000_0000地址處內存（所以我們當然期望，它總是命中著），由于系統調度，這一次該線程可能跑在cpu0上，下一次也許就跑在cpu1上了，再下一次也許就是cpu4上了(其實這種行為也叫做CPU migration)

或者舉個這樣的場景也行：在Linux Kernel系統中，定義了一個全局性的變量，然后多個內核線程(多個CPU)都會訪問該變量.

在以上的場景中，都存在一塊內存(如0x4000_0000地址處內存)被不同的ARM CORE來訪問，這樣就會出現了該數據在main-memory、cluster cache、core cache不一致的情況, 復雜點場景可能還會考慮cluster chache和other Master(如GPU) cache的一致性情況。

既然出現了數據在內存和不同的cache中的不一致的情況，那么就需要解決這個問題（也叫維護cache一致性），那么怎么維護的呢，上面也說了“使用 硬件管理的一致性”，下面就以直接寫答案的方式，告訴你硬件是怎樣維護一致性的。

2.1 多核緩存一致性

同一個cluster中多core之間的緩存一致性由DSU(big.LITTLE叫SCU)來維護，遵循MESI協議。

2.2 多Master之間的緩存一致性

在講述多Master之間的緩存一致性之前，我們先將Master分為以下幾類：

ACE Master : 如 big.LITTLE cluster 或 DSU cluster

CHI Master : 如 big.LITTLE cluster 或 DSU cluster

ACE-lite Master：如 GPU cluster

I/O Device Master : 如 DMA

以下是多Master之間的緩存一致性的結論：

首先，CHI/ACE總線都是支持MESI協議數據傳輸的

Master與I/O Device Master之間沒有一致性，因為I/O Device沒有鏈接到CCI/CMN緩存互聯總線上。

多個ACE/CHI Master之間的緩存一致性，是否遵循MESI，要具體情況具體分析，簡而言之就是：(1) 如果兩個Master都支持帶MESI狀態位，支持帶有MESI信號的讀寫，那么這兩個Master緩存一致性是遵從MESI協議的 (2) 如果有一個Master不支持帶MESI狀態位，那么這個Master就無法支持帶有MESI信號的讀寫，那么這兩個Master緩存一致性是不遵從MESI協議的 (3) Master的MESI狀態位，是在該Master的cache的TAG中。

ACE/CHI Master和ACE-lite Master之間的緩存一致性，是不遵從MESI協議的。這主要是因為ACE/CHI Master無法snoop ACE-lite Master的內存，而ACE-lite Master卻可以snoop ACE/CHI Master的內存，總得來說，這不是一個完整的MESI協議。

舉一個最常見的例子：兩個DSU cluster的L3 cache中的TAG中，是有MESI比特位的，這兩個DSU通過ACE/CHI 接口發起的讀寫是帶有MESI信號的，所以他們是支持MESI協議的。

再舉一個例子，一個DSU cluster 和一個接到SMMU上的DMA，此時正好對應一個是ACE/CHI Master，一個ACE-lite Master，由于DMA/SMMU中并沒有MESI狀態位，他們也不會發起帶有MESI信號的讀寫，所以這兩個Master之間是不支持MESI協議的。

2.3dynamIQ架構同一個core中的L1和L2 cache

dynamIQ架構core中的L1和L2 cache不存在緩存一致性的問題，但有分配和替換策略。

我們先看一下DynamIQ架構中的cache中新增的幾個概念：

(1)Strictly inclusive: 所有存在L1 cache中的數據，必然也存在L2 cache中

(2)Weakly inclusive: 當miss的時候，數據會被同時緩存到L1和L2，但在之后，L2中的數據可能會被替換

(3)Fully exclusive: 當miss的時候，數據只會緩存到L1

其實inclusive/exclusive屬性描述的正是是 L1和L2之間的替換策略，這部分是硬件定死的，軟件不可更改的。

我們再以 ARMV9 cortex-A710為例，查看其TRM手冊，得知：

L1 I-cache和L2之間是 weakly inclusive的

L1 D-cache和L2之間是 strictly inclusive的

也就是說：

當發生D-cache發生miss時，數據緩存到L1 D-cache的時候，也會被緩存到L2 Cache中，當L2 Cache被替換時，L1 D-cache也會跟著被替換

當發生I-cache發生miss時，數據緩存到L1 I-cache的時候，也會被緩存到L2 Cache中，當L2 Cache被替換時，L1 I- cache不會被替換

所以總結一下就是 ：L1 和 L2之間的cache的替換策略，針對I-cache和D-cache可以是不同的策略，每一個core都有每一個core的做法，這部分是硬件決定的，請查閱你使用core的TRM手冊。

3.MESI協議的介紹

本協議適用于：

big.LITTLE架構中多核緩存一致性

dynamIQ架構中多核緩存一致性

多cluster之間緩存一致性

其實也適用于：

不同cluster之間多核的緩存一致性

然后接下來，我們開始學習MESI協議，注意著僅僅是一個協議 ，它既不是軟件也不是硬件，算上一個標準吧。首先是Modified Exclusive Shared Invalid (MESI) 協議中定義了4個狀態:

其次，在ARM的部分的core中，定義了第五種狀態 SharedModified，這種稱之為 MOESI協議.我查詢大量的Core的TRM手冊，信息如下：

使用MESI協議的core有：A710 A510 A78 A77 A76 A75 A72 A57 A55...

使用MOESI協議的core有：A7 A15 A53

發現問題了沒？并不是網上主流博客所說，arm一般都用MOESI。請記住arm主流core在使用的是MESI。所以接下來，我們也不會再介紹和學習MOESI了。

然后我們通過數據流圖的方式，觀看下MESI這四種狀態的情況:

MESI狀態之間的切換:

Events:RH = Read HitRMS = Read miss, sharedRME = Read miss, exclusiveWH = Write hitWM = Write missSHR = Snoop hit on readSHI = Snoop hit on invalidateLRU = LRU replacement
Bus Transactions:Push = Write cache line back to memoryInvalidate = Broadcast invalidateRead = Read cache line from memory

學到這里，我們對多核之間緩存一致性也有了大概的理解，我們也知道了MESI是干啥的了，那么我們繼續拋幾個問題：(1)、為什么說“多核之間的緩存一致性，遵從MESI協議，是DSU/SCU來維護”的？

其實吧，這也不是我說的，這來自ARM官方文檔：

對于big.LITTLE架構，SCU是這樣描述的：

對于dynamIQ架構，DSU文檔中這樣描述的：

(2)、MESI的狀態位記錄在哪里的？以 ARMV9 cortex-A710為例，記錄在core cache的TAG中的BIT[1:0]中，即在TAG中。

對于big.LITTLE架構SCU的L2 cache、dynamIQ架構的DSU L3 cache中的TAG中，也都是有MESI比特位的，不過這一點在 armARMs和 trm文檔都是找不到的，不過在一些的PPT上是可以看到的。

4.ACE維護的緩存一致性

ACE master是接到 CCI 緩存互聯總線上的， 在 CCI Interconnect中，其實也是有一個Snoop Filter單元。ACE協議和Snoop filter單元一起來完成了ACE Master之間的緩存一致性。

snoop filter的主要作用：用于記錄存儲在ACE中的緩存。

Snoop Filter可以在未命中的情況下響應偵聽事務，并偵聽適當的主控只有在命中的情況下。Snoop Filter條目通過觀察來自 ACE 主節點的事務來維護以確定何時必須分配和取消分配條目。

Snoop Filter可以響應多個一致性請求，而無需向所有master廣播ACE 接口。例如，如果地址不在任何緩存中，則Snoop Filter會以未命中和將請求定向到內存。如果地址在處理器緩存中，則請求被視為命中，并且指向在其緩存中包含該地址的 ACE 端口。

以下也舉了一個多cluster之間緩存一致性的示例，A53 cluster讀取A57 cluster緩存一致性數據。

(1). Cortex-A53 cluster 發出 Coherent Read Request。

(2). CCI-400 將請求傳遞Request以窺探 Cortex-A57 cluster 緩存。

(3). 收到請求后，Cortex-A57 cluster會檢查其數據緩存的可用性并以所需信息進行響應。

(4). 如果請求的數據在緩存中，CCI-400 將數據從 Cortex-A57 cluster移動到 Cortex-A53 cluster，從而導致 Cortex-A53 cluster中的緩存行填充。

5.軟件定義的緩存和替換策略

以上的multi cores、multi cluster、system之間的緩存策略或協議，都是由硬件決定，軟件改不了。那么我們軟件可以做什么呢？其實，在軟件的MMU頁表的entry中的屬性位中，是可以定義該頁面內存的緩存策略的。如果軟件定義了內存位non-cacheable或non-shareable，那么以上的"硬件維護的一致性"將不會生效。接下來對，軟件定義的緩存策略做了一個小小的總結。

總結了一下shareable、cacheable屬性對緩存策略的影響：

6.動圖示例

前置條件：dynamIQ架構、L1 Data weakly inclusive、讀寫的內存配置位outer-shareable/write-back cacheable
步驟:

(1)、core0 讀取了一行數據，數據緩存到了core0的L1 Dcache、L2 cache

(2)、隨后core0的L2 中的數據是有可能會被替換出

(3)、core1 也讀取了該行數據，數據緩存到了core1的L1 Dcache、L2 cache、L3 cache

(4)、隨后core1的L2 中的數據也是有可能會被替換出

(5)、core4 也讀取了該行數據，數據緩存到了core4的L1 Dcache、L2 cache

(6)、隨后core4的L2 中的數據也是有可能會被替換出

(7)、至此，core0的L1、core1的L1、cluster0的L3、core4的L1 中都緩存了該數據。core0的L2、core1的L2、core4的L2 可能緩存了該行數據

審核編輯 ：李倩