1.思考和質(zhì)疑

在一個大架構(gòu)大系統(tǒng)中，有哪些一致性需要維護(hù)？我們先看如下一張架構(gòu)圖。

然后請思考：

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

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

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

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

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

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

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

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

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

(2)、MESI是一個協(xié)議？是誰來維護(hù)的？總得有個硬件實(shí)現(xiàn)這個協(xié)議吧，是在ARM Core實(shí)現(xiàn)？DSU實(shí)現(xiàn)？

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

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

2.怎樣去維護(hù)多核多系統(tǒng)緩存的一致性

有三種機(jī)制可以保持一致性：

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

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

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

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

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

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

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

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

2.1 多核緩存一致性

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

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之間的緩存一致性的結(jié)論：

首先，CHI/ACE總線都是支持MESI協(xié)議數(shù)據(jù)傳輸?shù)?/p>

Master與I/O Device Master之間沒有一致性，因?yàn)镮/O Device沒有鏈接到CCI/CMN緩存互聯(lián)總線上。

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

ACE/CHI Master和ACE-lite Master之間的緩存一致性，是不遵從MESI協(xié)議的。這主要是因?yàn)锳CE/CHI Master無法snoop ACE-lite Master的內(nèi)存，而ACE-lite Master卻可以snoop ACE/CHI Master的內(nèi)存，總得來說，這不是一個完整的MESI協(xié)議。

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

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

2.3dynamIQ架構(gòu)同一個core中的L1和L2 cache

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

我們先看一下DynamIQ架構(gòu)中的cache中新增的幾個概念：

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

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

(3)Fully exclusive: 當(dāng)miss的時(shí)候，數(shù)據(jù)只會緩存到L1

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

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

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

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

也就是說：

當(dāng)發(fā)生D-cache發(fā)生miss時(shí)，數(shù)據(jù)緩存到L1 D-cache的時(shí)候，也會被緩存到L2 Cache中，當(dāng)L2 Cache被替換時(shí)，L1 D-cache也會跟著被替換

當(dāng)發(fā)生I-cache發(fā)生miss時(shí)，數(shù)據(jù)緩存到L1 I-cache的時(shí)候，也會被緩存到L2 Cache中，當(dāng)L2 Cache被替換時(shí)，L1 I- cache不會被替換

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

3.MESI協(xié)議的介紹

本協(xié)議適用于：

big.LITTLE架構(gòu)中多核緩存一致性

dynamIQ架構(gòu)中多核緩存一致性

多cluster之間緩存一致性

其實(shí)也適用于：

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

然后接下來，我們開始學(xué)習(xí)MESI協(xié)議，注意著僅僅是一個協(xié)議 ，它既不是軟件也不是硬件，算上一個標(biāo)準(zhǔn)吧。首先是Modified Exclusive Shared Invalid (MESI) 協(xié)議中定義了4個狀態(tài):

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

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

使用MOESI協(xié)議的core有：A7 A15 A53

發(fā)現(xiàn)問題了沒？并不是網(wǎng)上主流博客所說，arm一般都用MOESI。請記住arm主流core在使用的是MESI。所以接下來，我們也不會再介紹和學(xué)習(xí)MOESI了。

然后我們通過數(shù)據(jù)流圖的方式，觀看下MESI這四種狀態(tài)的情況:

MESI狀態(tài)之間的切換:

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

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

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

對于big.LITTLE架構(gòu)，SCU是這樣描述的：

對于dynamIQ架構(gòu)，DSU文檔中這樣描述的：

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

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

4.ACE維護(hù)的緩存一致性

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

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

Snoop Filter可以在未命中的情況下響應(yīng)偵聽事務(wù)，并偵聽適當(dāng)?shù)闹骺刂挥性诿械那闆r下。Snoop Filter條目通過觀察來自 ACE 主節(jié)點(diǎn)的事務(wù)來維護(hù)以確定何時(shí)必須分配和取消分配條目。

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

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

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

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

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

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

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

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

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

6.動圖示例

前置條件：dynamIQ架構(gòu)、L1 Data weakly inclusive、讀寫的內(nèi)存配置位outer-shareable/write-back cacheable
步驟:

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

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

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

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

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

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

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

審核編輯 ：李倩