CPU緩存冷門知識講解

由于CPU是核心硬件，相信我們在選擇CPU的時候都會去關心CPU參數方面，而在CPU核心參數中，我們經常會看到緩存(Cache)這個參數，那么CPU緩存有什么用?下面就讓小編帶你去看看CPU緩存冷門知識講解，希望能幫助到大家!

計算機組成原理 - CPU 高速緩存

按道理來說，循環1 花費的時間應該是循環2 的 16 倍左右。但實際上，循環1 在我的電腦上運行需要 50 毫秒，循環2 只需要 46 毫秒。相差在 15% 之內，1 倍都沒有。

這就是 CPU Cache (高速緩存)帶來的效果。

程序執行時，CPU 將對應的數據從內存中讀取出來，加載到 CPU Cache 里。這里注意，CPU 是一小塊一小塊來讀取數據的，而不是按照單個數組元素來讀取數據的。

這一小塊一小塊的數據，在 CPU Cache 里面，我們把它叫作 Cache Line(緩存塊)。

日常用的 Intel 服務器或者 PC 中，Cache Line 的大小通常是 64 字節。

上面的循環2 里面，每隔 16 個整型數計算一次，16 個整型數正好是 64 個字節。所以，循環1 和循環2，都需要把同樣數量的 Cache Line 數據從內存中讀取到 CPU Cache 中，導致兩個程序花費的時間就差別不大了。

CPU Cache 一般有三層，L1/L2 單核私有，L3 多核共享緩存(這里的 L1-L3 指特定的由 SRAM 組成的物理芯片，不是概念上的緩存)。有了 CPU Cache，內存中的指令、數據，會被加載到 L1-L3 Cache 中，95% 的情況下，CPU 都只需要訪問 L1-L3 Cache，而無需訪問內存。

Cpu Cache 讀取數據

現代 CPU 進行數據讀取的時候，無論數據是否已經存儲在 Cache 中，CPU 始終會首先訪問 Cache。只有當 CPU 在 Cache 中找不到數據的時候，才會去訪問內存，并將讀取到的數據寫入 Cache 之中。

那么，Cache 如何根據內存地址定位到數據呢?

根據內存地址的低位，計算在 Cache 中的索引;

判斷有效位，確認 Cache 中的數據是有效的;

對比內存地址的高位，和 Cache 中的組標記，確認 Cache 中的數據就是我們要訪問的內存數據，從 Cache Line 中讀取到對應的數據塊(Data Block);

根據內存地址的Offset位，從Data Block中，讀取希望讀取到的字

如果在2、3這兩個步驟中，CPU 發現，Cache 中的數據并不是要訪問的內存地址的數據，那 CPU 就會訪問內存，并把對應的 Block Data 更新到 Cache Line 中，同時更新對應的有效位和組標記的數據。

總結一下，一個內存的訪問地址，最終包括高位代表的組標記、低位代表的索引，以及在對應的Data Block中定位對應字的位置偏移量。

Cpu Cache 寫入數據

當 Cpu 要寫入數據時，到底是寫 Cache 還是寫主存呢，如何保證一致性呢?

這里介紹兩種寫入策略。

1. 寫直達(Write-Through)

寫入前，我們會先去判斷數據是否已經在 Cache 里面了。如果數據已經在 Cache 里面了，我們先把數據寫入更新到 Cache 里面，再寫入到主內存里面;如果數據不在 Cache 里，我們就只更新主內存。

這個策略很直觀，但是問題也很明顯，那就是這個策略很慢。無論數據是不是在 Cache 里面，我們都需要把數據寫到主內存里面。這個方式就有點兒像 Java 里 volatile 關鍵字，始終都要把數據同步到主內存里面。

2. 寫回(Write-Back)

如果要寫入的數據，就在 CPU Cache 里面，那么就只更新 CPU Cache 里面的數據。同時標記 CPU Cache 里的這個 Block 是臟(Dirty)的。就是這個時候，CPU Cache 里的這個 Block 的數據，和主內存是不一致的。

如果要寫入的數據所對應的 Cache Block 里，放的是別的內存地址的數據，那么就要看一看，Cache Block 里的數據有沒有被標記成臟的。如果是臟的，要先把這個 Cache Block 里面的數據，寫入到主內存里面。然后，再把當前要寫入的數據，寫入到 Cache 里，同時把 Cache Block 標記成臟的。如果 Block 里面的數據沒有被標記成臟的，那么我們直接把數據寫入到 Cache 里面，然后再把 Cache Block 標記成臟的就好了。

然而，無論是寫回還是寫直達，都沒有解決多線程，或者是多個 CPU 核的緩存一致性的問題。

這也就是我們在寫入修改緩存后，需要解決的第二個問題。

要解決這個問題，我們需要引入一個新的方法，叫作 MESI 協議。這是一個維護緩存一致性協議。這個協議不僅可以用在 CPU Cache 之間，也可以廣泛用于各種需要使用緩存，同時緩存之間需要同步的場景下。

多核 CPU Cache 緩存一致性

因為多核 CPU Cache 在 L3 緩存是共享的，所以一致性問題，只會出現在 L1/L2 級這種單核私有緩存的場景中。

我們需要有一種機制，來同步兩個不同核心里面的緩存數據。這樣的機制需要滿足兩點：

第一點叫寫傳播(Write Propagation)。寫傳播是說，在一個CPU核心里，我們的Cache數據更新，必須能夠傳播到其他的對應節點的Cache Line里。

第二點叫事務的串行化(Transaction Serialization)，事務串行化是說，我們在一個CPU核心里面的讀取和寫入，在其他的節點看起來，順序是一樣的。

CPU Cache 里做到事務串行化，需要做到兩點，第一點是一個 CPU 核心對于數據的操作，需要同步通信給到其他 CPU 核心。第二點是，如果兩個 CPU 核心里有同一個數據的 Cache，那么對于這個 Cache 數據的更新，需要有一個“鎖”的概念。只有拿到了對應 Cache Block 的“鎖”之后，才能進行對應的數據更新。接下來，我們就看看實現了這兩個機制的 MESI 協議。

MESI 協議，是一種叫作寫失效(Write Invalidate)的協議。在寫失效協議里，只有一個 CPU 核心負責寫入數據，其他的核心，只是同步讀取到這個寫入。在這個 CPU 核心寫入 Cache 之后，它會去廣播一個“失效”請求告訴所有其他的 CPU 核心。其他的 CPU 核心，只是去判斷自己是否也有一個“失效”版本的 Cache Block，然后把這個也標記成失效的就好了。

MESI協議的由來呢，來自于我們對 Cache Line 的四個不同的標記，分別是：

M：代表已修改(Modified) E：代表獨占(E__clusive) S：代表共享(Shared) I：代表已失效(Invalidated)

我們先來看看“已修改”和“已失效”，這兩個狀態比較容易理解。所謂的“已修改”，就是我們上一講所說的“臟”的 Cache Block。Cache Block 里面的內容我們已經更新過了，但是還沒有寫回到主內存里面。而所謂的“已失效“，自然是這個 Cache Block 里面的數據已經失效了，我們不可以相信這個 Cache Block 里面的數據。

然后，我們再來看“獨占”和“共享”這兩個狀態。這就是 MESI 協議的精華所在了。無論是獨占狀態還是共享狀態，緩存里面的數據都是“干凈”的。這個“干凈”，自然對應的是前面所說的“臟”的，也就是說，這個時候，Cache Block 里面的數據和主內存里面的數據是一致的。

那么“獨占”和“共享”這兩個狀態的差別在哪里呢?這個差別就在于，在獨占狀態下，對應的 Cache Line 只加載到了當前 CPU 核所擁有的 Cache 里。其他的 CPU 核，并沒有加載對應的數據到自己的 Cache 里。這個時候，如果要向獨占的 Cache Block 寫入數據，我們可以自由地寫入數據，而不需要告知其他 CPU 核。

在獨占狀態下的數據，如果收到了一個來自于總線的讀取對應緩存的請求，它就會變成共享狀態。這個共享狀態是因為，這個時候，另外一個 CPU 核心，也把對應的 Cache Block，從內存里面加載到了自己的 Cache 里來。

而在共享狀態下，因為同樣的數據在多個 CPU 核心的 Cache 里都有。所以，當我們想要更新 Cache 里面的數據的時候，不能直接修改，而是要先向所有的其他 CPU 核心廣播一個請求，要求先把其他 CPU 核心里面的 Cache，都變成無效的狀態，然后再更新當前 Cache 里面的數據。這個廣播操作，一般叫作 RFO(Request For Ownership)，也就是獲取當前對應 Cache Block 數據的所有權。

有沒有覺得這個操作有點兒像我們在多線程里面用到的讀寫鎖。在共享狀態下，大家都可以并行去讀對應的數據。但是如果要寫，我們就需要通過一個鎖，獲取當前寫入位置的所有權。

整個 MESI 的狀態，可以用一個有限狀態機來表示它的狀態流轉。需要注意的是，對于不同狀態觸發的事件操作，可能來自于當前 CPU 核心，也可能來自總線里其他 CPU 核心廣播出來的信號。我把對應的狀態機流轉圖放在了下面，你可以對照著 Wikipedia 里面 MESI 的內容，仔細研讀一下。

為什么CPU有多層緩存

緩存的故事

假設你是一位六十年代的白領，在巨大的辦公樓里工作，沒有電腦，你需要閱讀大量的文件并且交叉檢索這些文檔。

你有一個辦公桌(L1 緩存)。桌上的文件是你正在手頭處理的資料，還有一些是你最近看過的或者你準備閱讀的。通常我們需要閱讀文件的每一頁(對應于存儲單元的一個字節)，但除非它們在辦公桌上，文件都是作為一個整體。即只想看某一頁的內容，我們也必須把整份文件抓過來。

辦公室里還有文件柜(L2 緩存)。這些文件柜里存放的是你最近處理過，但目前沒有在使用的文件。辦公桌上的文件在用完后，通常也會放回文件柜。從文件柜里拿文件就不是順手拈來了——你需要走過去，打開相應的抽屜，還要查目錄卡片，才能找到想要的文件——不過這也還比較快了。

有些時候，其他人也需要查看你的文件柜里的文件。勤雜工會推著一輛推車(環路公共汽車)在各個辦公室轉。如果有人在自己的文件柜沒有找到相應的資料，他會寫一個紙條交給勤雜工。為簡化起見，假設這位勤雜工知道所有的東西放哪兒。所以當他來到你的辦公室的時候，他會檢查你的文件柜里是否有其他人需要的文件，如果有，就把這些文件抽出來放到車上。當他轉到別的辦公室，就會把找到的文件放在文件柜里，并留下收條。

有時候，這些文件并不在文件柜里，而是在辦公桌上。那就不可以直接拿了，需要征詢主人的意見，如果不行，大家就要商量如何協調。有大量冗長的詳盡的合作指引來處理這類情況(至少要一起開會)。

文件柜經常會滿，這時就不能放新的文件，需要先騰地方，把一些很久都沒用到的文件拿出來。勤雜工會把這些文件放到地下室里(L3 緩存)。地下室里的文件被密集地堆放到紙箱里或者文件架上，交給文檔管理員處理，其他人都不會下去，也不會了解文檔的存放細節。

當勤雜工來到地下室，會把一堆不需要的文件放到‘in’框里，同時他也會留下一堆紙條，寫著在樓上文件柜里找不到的文件名。文檔管理員會拿著這些紙條，找到對應的文件，把它們放到‘out’ 框里。下次勤雜工下來的時候，就可以把‘out’框里的文件拿走，交給需要的人。

現在的問題是，文件還是太多，地下室也放不下，而且辦公大樓的租金都很貴，所以通常公司都會在離市區較遠的地方租一個倉庫來存放歸檔文件(對應于DRAM內存)。文檔管理員會記錄哪些文件放在地下室，哪些文件放在倉庫。這樣，當需要拿文件時，管理員就知道哪些是能在地下室找到，哪些要到倉庫里拿。每天有一兩次，會有一輛貨車開到倉庫去拿需要的文件，同時把一些地下室的舊文件運過去。

對勤雜工而言，他并不關心這些細節，這些都是文檔管理員在處理。他需要做的就是把紙條放到‘in’框里，從‘out’框里取出文件。

回到最初的問題

那么，這個類比的意義何在?簡短而言，一個具體的模型比模糊的概念更能清晰地闡明物流的意義。實際上，物流對設計芯片的意義和運作一個高效的辦公文件處理系統是一樣的。

最初的問題是‘為什么不用一個大的緩存，而是用幾層小的緩存?’。 也就是說，如果一個4核芯片配置32K一級緩存，256K二級緩存和2M三級緩存，為什么不能用一個3M的大緩存?

在類比里，類似于問與其給4個人每人分一個1.5米寬的辦公桌，為什么不給這4個人一個150米寬的大辦公桌?

關鍵在于，放辦公桌上的目的就是要能觸手可及。如果辦公桌太大，就沒有意義了。難道還需要走50米去拿文件? 對一級緩存也是同理，如果太大，存取速度會變慢，而且會消耗更多的電力。所以一級緩存既要足夠大到能起作用，又要小到能夠快速存取。

另外一點，一級緩存處理的存取類型和其他緩存不同。有L1的數據緩存，也有L1指令緩存。Intel的CPU還有另外的指令緩存，uOp緩存，既叫L1并發指令緩存也叫L0指令緩存。

L1數據緩存通常只處理1到8個字節的數據，但高層級的緩存并不處理單獨的字節。在我們的類比里，所有不辦公桌上的資料都是以文件為單位(對應于catch line)。 在內存中也一樣，高層級緩存通常是批發處理數據，以緩存行為單位(cache line)。

L1指令緩存和數據緩存完全不同，就內核而言，它是只讀的。(指令內存的寫入通常是用非直接的方式，先把指令放入高層的緩存，再載入一級指令緩存)。由于這個原因，指令緩存和數據緩存通常是分隔的。使用通用的L1緩存意味著把互相沖突的設計原則糅合在一起，妥協的結果就是任何一個目的都達不到。而且用通用的L1緩存處理指令和數據負載也會很大。

另外，作為程序員，我們通常不關心內存帶寬。例如，每個時鐘周期，i7的CPU的內核能從L1緩存中讀取16字節的指令，而且會不斷地循環讀取。如果是3GHZ,每個核可以讀50GB指令/秒。實際上，通常L1指令緩存的能力都足夠大，很少需要L2緩存參與處理。但如果是通用緩存，就需要預估指令和數據的高并發情況。(想象一下在L1緩存中用memcopy拷貝幾K數據的情況)

順便提一句，如果都在L1緩存，CPU能在一個時鐘周期完成許多存取操作。‘Haswell’或者之后的3GHZ的i7內核可以處理超過300GB的指令和數據, 如果搭配合理的話。這樣的處理能力綽綽有余，但你仍然需要考慮數據和指令同時出現峰值的情況。

L1緩存在設計上就是越快越好，以應對峰值情況。只有L1緩存處理不了，才會轉給更高層的緩存，但速度會降低。因為高層緩存更關心電力效率和存儲密度。

第三點，共享。在上面的比喻中，獨立辦公桌，亦或L1緩存是私有的，如果在你的辦公桌上，你只管拿就好了，不需要詢問其他人。

這很關鍵。如果4個人共享一個大辦公桌，你就不能隨便拿文件，因為另外三個人可能正在使用。(即使他們只是在閱讀其他文件時順便參考一下你想使用的文件)。任何時候，你想要拿什么東西，你需要先叫一聲，‘有人在用嗎?’如果別人在你前面，你就必須等待。或者需要一個排隊系統，當存在資源沖突的時候，每個人需要拿張票排隊等候，或者其它的什么機制，具體實現細節并不重要，但是所有的事情你都需要和其他人協調。

對多核共享緩存的情況也是這樣。你不能在不通知別人的情況下隨意動那些數據，所有對共享緩存的操作都必須協調進行。

這就是為什么我們要使用私有的L1緩存。L1緩存就是你的辦公桌，你可以隨便使用桌上的文件。L2緩存處理大部分的協同操作。大部分時間，工作者(CPU內核)坐在辦公桌前，勤雜工會走過來，把需求列表拿走，同時把之前你想找的文件放倒文件柜里。整個過程不會打斷你的工作(CPU)。

僅僅當你和勤雜工都需要拿文件柜里的同一份文件，或者別人想用你辦公桌上的文件，這時就需要停下手頭工作，進行交談。

簡單而言，L1緩存的工作就是優先為CPU內核服務。因為是私有的，所以基本不需要協調工作。L2緩存也是私有的，但是它的工作重心還包括在不打擾內核工作的情況下，處理大量的緩存間的數據通信。

L3緩存是共享資源，需要全局協調。在上面的類比中，工作者只有從勤雜工的推車里拿到文件，這就是一個阻塞點。我們只能希望L1和L2緩存足夠大以便這類阻塞點不會成為性能瓶頸。

附加說明

本篇文章涵蓋了當前臺式機(筆記本)CPU的緩存架構：分開的L1/L1 D 緩存，每核統一的L2緩存，共享的L3緩存。

不是每個系統都象這樣。一些系統并不區分指令緩存和數據緩存;另外一些則把指令和數據在所有的緩存級全部分開。很多L2緩存是多核共享的，L2緩存就象是連接多個內核的公共汽車。還有一些系統有L3和L4緩存。我也沒有提到使用多CPU套接字的系統。

我提到環路公共汽車是因為這是一個很好的類比。環路公共汽車很常見。有些時候，環路汽車是個麻煩(尤其是只需要把兩三個街區連起來);有時候,環路公共汽車需要和交叉系統連接起來(就象在辦公室，每個樓層用推車，不同樓層則用電梯)。

作為軟件工程師，我們自然而然地會假設模塊A和模塊B可以魔術般地連接，數據則可隨意地從一端流向另一端。內存的實際工作機制其實非常復雜，但抽象出來呈現給程序員的只是一組大平面的字節排列。

硬件并不象這樣工作。各個部件之間并不能魔法般地自動連接。模塊A和模塊B并非抽象概念，而是具體的物理設備，實際上可以看作是非常小的機器，在硅片上占有實際的物理空間。芯片都有平面圖，是真正的2D地圖。如果你想連接A和B，就需要一條實際的導線來連接。 導線也占空間，而且需要消耗電力(越遠消耗越多)。用一大捆線連接A和B意味著物理上這一塊區域會阻礙其他區域的連接。(當然，芯片可以使用多層連接，如果你有興趣，可以搜索‘routing congestion’)。 在芯片里移動數據實際上是一個物流問題，并且超級復雜。

所以盡管辦公室的故事只是半開玩笑的類比，‘誰需要和誰談’、‘這個系統的幾何構造如何——是有意義的布局嗎?’這些問題其實對系統設計和硬件相關并有巨大的影響。 利用空間的隱喻來概念化實際情況是十分有效的。

Intel CPU漏洞技術解讀：都是緩存惹的禍!

原因一切還是要從CPU指令執行的框架——流水線說起。Intel當然不至于明知你要用一個用戶態的進程讀取Kernel內存還會給你許可。但現代CPU流水線的設計，尤其是和性能優化相關的流水線的特性，讓這一切充滿了變數。

給所有還沒有看過云杉網絡連載的系列文章《__86高性能編程箋注系列》的讀者一點背景知識的介紹：

__86 CPU為了優化性能，在處理器架構方面做了很多努力。諸如“多級緩存”這一類的特性，是大家都比較熟悉的概念。還有一些特性，比如分支預測和亂序執行，也都是一些可以從并行性等方面有效提升程序性能的特性，并且它們也都是組成流水線的幾個關鍵環節。即便你暫時還不能準確理解其含義，但望文生義，也能看出來這肯定是兩個熵增的過程。熵增帶來無序，無序就會帶來更多漏洞。

緩存的困境講緩存，必然先掛一張memory hierarchy鎮樓：

不過我要說的和這個沒太大關系。現在需要考慮的是，如果能讀取到內核地址的內容，那這部分內容最終肯定是跑到緩存中去了，因為真正直接和CPU核心交互的存儲器，就是緩存。這對一級緩存(L1 Cache，業內也常用縮寫L1$，取cash之音)提出的要求就是，必須要非常快，唯有如此才能跟上CPU處理核心的速度。

Side Notes: 為什么在不考慮成本的情況下緩存不是越大越好，也是因為當緩存規模越大，查找某一特定數據就會越慢。而緩存首先要滿足的要求就是快，其他的都是次要的。

根據內核的基本知識我們知道，進程運行時都有一個虛擬地址「Virtual address」和其所對應的物理地址「physical address」。

從虛擬地址到物理地址的翻譯轉換也由CPU通過page table完成。Page table并不儲存在CPU里，但近期查找到的Page table entry「PTE」都像數據一樣，緩存在了CPU中的translation lookaside buffer「TLB」里。為了不再過多堆砌術語和名詞，畫張圖說明一下：

當CPU根據程序要求需要讀取某個地址上的數據時，首先會在L1 Cache中查找。為了適應CPU的速度，L1緩存實現為Virtually inde__ed physically tagged「VIPT」的形式，即用虛擬地址即可直接讀取該虛擬地址對應的物理地址的內容，而不再需要多加一道轉換的工序。

如果L1 Cache miss，則會在下級緩存中查找。但越過L1 Cache之后，對L2$和L3$的速度要求就不再這么嚴苛。此時CPU core給出的虛擬地址請求會先通過TLB轉換為物理地址，再送入下級緩存中查找。而檢查進程有沒有權限讀取某一地址這一過程，僅在地址轉換的時候發生，而這種轉換和檢查是需要時間的，所以有意地安排在了L1 Cache之后。

L1緩存這種必須求“快”的特性，成了整個事件的楔子。

分支預測分支預測是一種提高流水線執行效率的手段。在遇到if..else..這種程序執行的分支時，可以通過以往的歷史記錄判斷哪一分支是最可能被執行的分支，并在分支判斷條件真正返回判斷結果之前提前執行分支的代碼。詳情可以在上面提到的連載文章中閱讀。

需要強調的是，提前執行的分支代碼，即便事后證明不是正確的分支，其執行過程中所讀取的數據也可以進入L1緩存。在Intel的官網文檔《Intel? 64 and IA-32 Architectures Optimization Reference Manual》第2.3.5.2節中指：

L1 DCache Loads:

- Be carried out speculatively, before preceding branches are resolved.

- Take cache misses out of order and in an overlapped manner.

Show you the [偽] code:

if (likely(A < B)) { value = __(kernel_address_pointer);}

當分支判斷條件A < B被預測為真時，CPU會去提前執行對內核地址的讀取。當實際條件為A > B時，雖然內核的值不會真正寫入寄存器(沒有retire)，但會存入L1 Cache，再加之上一節介紹的，獲取L1 Cache的值毋須地址轉換，毋須權限檢查，這就為內核信息的泄漏創造了可能。

從理論上來講，如果可以控制程序的分支判斷，并且可以獲取L1緩存中的數據(這個沒有直接方法，但可以通過其他間接手法)的話，就完全可以獲取內核信息。而分支預測這種特性是不能隨隨便便就關閉的，這也就是這次問題會如此棘手的原因。

亂序執行還有一個原因是亂序執行，但原理大致類似。亂序執行是Intel在1995年首次引入Pentium Pro處理器的機制。其過程首先是將我們在匯編代碼中看到的指令“打散”，成為更細粒度的微指令「micro-operations」，更小的指令粒度將會帶來更多的亂序排列的組合，CPU真正執行的是這些微指令。

沒有數據依賴的微指令在有相應執行資源的情況下亂序并行執行，進而提升程序的并行程度，提高程序性能。但引入的問題是，讀取內核數據的微指令可能會在流水線發出e__ception之前將內核數據寫入L1 Cache。與分支選擇一樣，為通過用戶態進程獲取內核代碼提供了可能。

限于篇幅，更詳細的內容讀者可以在國外安全團隊發布的消息中獲取。

后續剛剛查閱之前連載中的一些細節的時候，看到在“流水線”那一章里寫過這樣一段話：

在面對問題的時候，人總是會傾向于引入一個更復雜的機制來解決問題，多級流水線就是一個例子。復雜可以反映出技術的改良，但“復雜”本身就是一個新的問題。這也許就是矛盾永遠不會消失，技術也不會停止進步的原因。但“為學日益，為道日損”，愈發復雜的機制總會在某個時機之下發生大破大立，但可能現在時機還沒有到來:D

很難講現在是不是就是所謂的那個“時機”。雖然對整個行業都產生了負面影響，但我對此仍保持樂觀。因為這就是事物自然發展的一個正常過程。性能損失并不是一件壞事，尤其是對牙膏廠的用戶來說。

CPU緩存冷門知識講解相關文章：

★ cpu緩存低有什么缺點

★ 如何清理CPU緩存