今天分享一篇內存性能優化的文獻，文獻采用了大量精美的圖解，深入淺出地分析了 linux 內核 slab 性能優化的核心原則。

slab是 Linux 內核中用于小對象內存分配的主要算法，文獻探討了在不同場景下內存分配可能出現的各種性能問題，并提供了優化方案。這對于我們設計高性能內存池算法或者在未來處理內存性能問題時具有一定的啟示，值得我們借鑒。

Linux 內核的 slab源自一種簡單的想法，即預先準備一些常被頻繁分配和釋放的數據結構。然而，標準的 slab 實現過于復雜且維護成本高，于是演變出了更為精簡的 slub 算法，因此本文所討論的是 slub，稍后提及的 slab 都指 slub。

由于本文主要關注內核優化方面的內容，若想深入了解 slab 的細節和代碼實現，請參閱源碼。

單CPU場景下簡單的slab算法

下列圖示展示了在單個 CPU 上，slab 在分配和釋放對象時的情景序列：

可以看出，非常之簡單，而且完全達到了slab設計之初的目標。

擴展到多核心CPU

現在我們簡單地將上面的模型擴展到多核心CPU，同樣差不多的分配序列如下圖所示：

我們看到，在只有單一slab的時候，如果多個CPU同時分配對象，沖突是不可避免的，解決沖突的幾乎是唯一的辦法就是加鎖排隊，然而這將大大增加延遲，我們看到，申請單一對象的整個時延從T0開始，到T4結束，這太久了。

多CPU無鎖化并行化操作的直接思路：復制給每個CPU一套相同的數據結構不二法門就是增加“每CPU變量”。對于slab而言，可以擴展成下面的樣子：

如果以為這么簡單就結束了，那這就太沒有意義了。

問題

首先，我們來看一個簡單的問題，如果單獨的某個CPU的 slab 緩存沒有對象可分配了，但是其它 CPU 的 slab 緩存仍有大量空閑對象的情況，如下圖所示：

這是可能的，因為對單獨一種slab的需求是和該CPU上執行的進程/線程緊密相關的，比如 如果CPU0只處理網絡，那么它就會對skb等數據結構有大量的需求，對于上圖最后引出的問題，如果我們選擇從伙伴系統中分配一個新的page(或者pages，取決于對象大小以及slab cache的order)，那么久而久之就會造成slab在CPU間分布的不均衡，更可能會因此吃掉大量的物理內存，這都是不希望看到的。

在繼續之前，首先要明確的是，我們需要在CPU間均衡slab，并且這些必須靠slab內部的機制自行完成，這個和進程在CPU間負載均衡是完全不同的，對進程而言，擁有一個核心調度機制，比如基于時間片，或者虛擬時鐘的步進速率等，但是對于slab，完全取決于使用者自身，只要對象仍然在使用，就不能剝奪使用者繼續使用的權利，除非使用者自己釋放。因此slab的負載均衡必須設計成合作型的，而不是搶占式的。

好了。現在我們知道，從伙伴系統重新分配一個page(s)并不是一個好主意，它應該是最終的決定，在執行它之前，首先要試一下別的路線。

現在，我們引出第二個問題，如下圖所示：

誰也不能保證分配slab對象的CPU和釋放slab對象的CPU是同一個CPU，誰也不能保證一個CPU在一個slab對象的生命周期內沒有分配新的page(s)，這期間的復雜操作誰也沒有規定。這些問題該怎么解決呢？事實上，理解了這些問題是怎么解決的，一個slab框架就徹底理解了。

問題的解決-分層slab cache

無級變速總是讓人向往。如果一個CPU的slab緩存滿了，直接去搶同級別的別的CPU的slab緩存被認為是一種魯莽且不道義的做法。

那么為何不設置另外一個slab緩存，獲取它里面的對象不像直接獲取CPU的slab緩存那么簡單且直接，但是難度卻又不大，只是稍微增加一點消耗，這不是很好嗎？

事實上，CPU的L1，L2，L3 cache不就是這個方案設計的嗎？這事實上已經成為cache設計的不二法門。這個設計思想同樣作用于slab，就是Linux內核的slub實現，現在可以給出概念和解釋了。

1. Linux kernel slab cache：一個分為3層的對象cache模型。
2. Level 1 slab cache：一個空閑對象鏈表，每個CPU一個的獨享cache，分配釋放對象無需加鎖。
3. Level 2 slab cache：一個空閑對象鏈表，每個CPU一個的共享page(s) cache，分配釋放對象時僅需要鎖住該page(s)，與Level 1 slab cache互斥，不互相包容。
4. Level 3 slab cache：一個page(s)鏈表，每個NUMA NODE的所有CPU共享的cache，單位為page(s)，獲取后被提升到對應CPU的Level 1 slab cache，同時該page(s)作為Level 2的共享page(s)存在。
5. **共享page(s)**：該page(s)被一個或者多個CPU占有，每一個CPU在該page(s)上都可以擁有互相不充圖的空閑對象鏈表，該page(s)擁有一個唯一的Level 2 slab cache空閑鏈表，該鏈表與上述一個或多個Level 1 slab cache空閑鏈表亦不沖突，多個CPU獲取該Level 2 slab cache時必須爭搶，獲取后可以將該鏈表提升成自己的Level 1 slab cache。

該 slab cache 的圖示如下：

其行為如下圖所示：

2個場景

對于常規的對象分配過程，下圖展示了其細節：

事實上，對于多個CPU共享一個page(s)的情況，還可以有另一種玩法，如下圖所示：

伙伴系統

前面我們簡短的體會了Linux內核的slab設計,不宜過長,太長了不易理解.但是最后,如果Level 3也沒有獲取page(s)，那么最終會落到終極的伙伴系統，伙伴系統是為了防內存分配碎片化的，所以它盡可能地做兩件事：

1. 盡量分配盡可能大的內存
2. 盡量合并連續的小塊內存成一塊大內存

我們可以通過下面的圖解來理解上面的原則：

注意，本文是關于優化的，不是伙伴系統的科普，所以我假設大家已經理解了伙伴系統。

鑒于slab緩存對象大多數都是不超過1個頁面的小結構(不僅僅slab系統，超過1個頁面的內存需求相比1個頁面的內存需求，很少)，因此會有大量的針對1個頁面的內存分配需求。從伙伴系統的分配原理可知，如果持續大量分配單一頁面，會有大量的order大于0的頁面分裂成單一頁面，在單核心CPU上，這不是問題，但是在多核心CPU上，由于每一個CPU都會進行此類分配，而伙伴系統的分裂，合并操作會涉及大量的鏈表操作，這個鎖開銷是巨大的，因此需要優化！

Linux內核對伙伴系統針對單一頁面的分配需求采取的批量分配“每CPU單一頁面緩存”的方式！每一個CPU擁有一個單一頁面緩存池，需要單一頁面的時候，可以無需加鎖從當前CPU對應的頁面池中獲取頁面。而當池中頁面不足時，系統會批量從伙伴系統中拉取一堆頁面到池中，反過來，在單一頁面釋放的時候，會擇優將其釋放到每CPU的單一頁面緩存中。

為了維持“每CPU單一頁面緩存”中頁面的數量不會太多或太少(太多會影響伙伴系統，太少會影響CPU的需求)，系統保持了兩個值，當緩存頁面數量低于low值的時候，便從伙伴系統中批量獲取頁面到池中，而當緩存頁面數量大于high的時候，便會釋放一些頁面到伙伴系統中。

小結

多CPU操作系統內核中，關鍵的開銷就是鎖的開銷。

我認為這是一開始的設計導致的，因為一開始，多核CPU并沒有出現，單核CPU上的共享保護幾乎都是可以用“禁中斷”，“禁搶占”來簡單實現的，到了多核時代，操作系統同樣簡單平移到了新的平臺，因此同步操作是在單核的基礎上后來添加的。

簡單來講，目前的主流操作系統都是在單核年代創造出來的，因此它們都是順應單核環境的，對于多核環境，可能它們一開始的設計就有問題。

不管怎么說，優化操作的不二法門就是禁止或者盡量減少鎖的操作。隨之而來的思路就是為共享的關鍵數據結構創建”每CPU的緩存“，而這類緩存分為兩種類型：

1. 數據通路緩存

比如路由表之類的數據結構，你可以用RCU鎖來保護，當然如果為每一個CPU都創建一個本地路由表緩存，也是不錯的，現在的問題是何時更新它們，因為所有的緩存都是平級的，因此一種批量同步的機制是必須的。

2. 管理機制緩存

比如slab對象緩存這類，其生命周期完全取決于使用者，因此不存在同步問題，然而卻存在管理問題。

采用分級cache的思想是好的，這個非常類似于CPU的L1/L2/L3緩存，采用這種平滑的開銷逐漸增大，容量逐漸增大的機制，并配合以設計良好的換入/換出等算法，效果是非常明顯的。