04-多核多cluster多系统之间缓存一致性概述
引流關鍵詞:緩存,高速緩存,cache, CCI,CMN,CCI-550,CCI-500,DSU,SCU,L1,L2,L3,system cache, Non-cacheable,Cacheable, non-shareable,inner-shareable,outer-shareable, optee、ATF、TF-A、Trustzone、optee3.14、MMU、VMSA、cache、TLB、arm、armv8、armv9、TEE、安全、內存管理、頁表…
快速鏈接:
.
👉👉👉 個人博客筆記導讀目錄(全部) 👈👈👈
目錄
- 1. 思考和質疑
- 2. 怎樣去維護多核多系統緩存的一致性
- 2. 1 多核緩存一致性
- 2. 2 多Master之間的緩存一致性
- 2. 3 `dynamIQ`架構同一個core中的L1和L2 cache
- 3. MESI協議的介紹
- 4、ACE維護的緩存一致性
- 5、軟件定義的緩存和替換策略
- 6、動圖示例
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 device Master一致性呢？遵從什么協議？
- (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. 3 dynamIQ架構同一個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個狀態:
| Modified (M) | 這行數據有效，數據已被修改，和內存中的數據不一致，數據只存在于該高速緩存中 |
| Exclusive (E) | 這行數據有效，數據和內存中數據一致，數據只存在于該高速緩存中 |
| Shared (S) | 這行數據有效，數據和內存中數據一致，多個高速緩存有這行數據的副本 |
| Invalid (I) | 這行數據無效 |
其次，在ARM的部分的core中，定義了第五種狀態Shared Modified，這種稱之為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 Hit
RMS = Read miss, shared
RME = Read miss, exclusive
WH = Write hit
WM = Write miss
SHR = Snoop hit on read
SHI = Snoop hit on invalidate
LRU = LRU replacement
Bus Transactions:
Push = Write cache line back to memory
Invalidate = Broadcast invalidate
Read = 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比特位的，不過這一點在arm ARMs和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屬性對緩存策略的影響：
| non-shareable | 數據不會緩存到cache （對于觀察則而言，又相當于outer-shareable） | core訪問該內存時，數據只緩存的到Core的 cache 中，不會緩存到其它cache中 | 同左側 |
| inner-shareable | 數據不會緩存到cache （對于觀察則而言，又相當于outer-shareable） | core訪問該內存時，數據只會緩存到core的cache和 cluster的 cache中，該地址的TAG也不會存到snoop filter中，即不會被其它ACE Master snoop | 同左側 |
| outer-shareable | 數據不會緩存到cache （對于觀察則而言，又相當于outer-shareable） | core訪問該內存時，數據只會緩存到core的cache和 cluster的 cache中，該地址的TAG會存到snoop filter中，會被其它ACE Master snoop | 同左側 |
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 可能緩存了該行數據
總結
以上是生活随笔為你收集整理的04-多核多cluster多系统之间缓存一致性概述的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 02-cache的基本概念原理扫盲
- 下一篇： 多级cache之间的替换(缓存)策略