背景
Read the fucking source code!--By 魯迅A picture is worth a thousand words.--By 高爾基
說明：
- Kernel版本：4.14
- ARM64處理器，Contex-A53，雙核
- 使用工具：Source Insight 3.5， Visio
1. 概述
之前的文章分析的都是基於頁面的內存分配，而小塊內存的分配和管理是通過塊分配器來實現的。目前內核中，有三種方式來實現小塊內存分配：slab, slub, slob，最先有slab分配器，slub/slob分配器是改進版，slob分配器適用於小內存嵌入式設備，而slub分配器目前已逐漸成為主流塊分配器。接下來的文章，就是以slub分配器為目標，進一步深入。
先來一個初印象：
2. 數據結構
有四個關鍵的數據結構：
struct kmem_cache：用於管理SLAB緩存，包括該緩存中對象的信息描述，per-CPU/Node管理slab頁面等；
關鍵字段如下：
/*
* Slab cache management.
*/
struct kmem_cache {
struct kmem_cache_cpu __percpu *cpu_slab; //每個CPU slab頁面
/* Used for retriving partial slabs etc */
unsigned long flags;
unsigned long min_partial;
int size; /* The size of an object including meta data */
int object_size; /* The size of an object without meta data */
int offset; /* Free pointer offset. */
#ifdef CONFIG_SLUB_CPU_PARTIAL
/* Number of per cpu partial objects to keep around */
unsigned int cpu_partial;
#endif
struct kmem_cache_order_objects oo; //該結構體會描述申請頁面的order值，以及object的個數
/* Allocation and freeing of slabs */
struct kmem_cache_order_objects max;
struct kmem_cache_order_objects min;
gfp_t allocflags; /* gfp flags to use on each alloc */
int refcount; /* Refcount for slab cache destroy */
void (*ctor)(void *); // 對象構造函數
int inuse; /* Offset to metadata */
int align; /* Alignment */
int reserved; /* Reserved bytes at the end of slabs */
int red_left_pad; /* Left redzone padding size */
const char *name; /* Name (only for display!) */
struct list_head list; /* List of slab caches */ //kmem_cache最終會鏈接在一個全局鏈表中
struct kmem_cache_node *node[MAX_NUMNODES]; //Node管理slab頁面
};
struct kmem_cache_cpu：用於管理每個CPU的slab頁面，可以使用無鎖訪問，提高緩存對象分配速度；
struct kmem_cache_cpu {
void **freelist; /* Pointer to next available object */ //指向空閑對象的指針
unsigned long tid; /* Globally unique transaction id */
struct page *page; /* The slab from which we are allocating */ //slab緩存頁面
#ifdef CONFIG_SLUB_CPU_PARTIAL
struct page *partial; /* Partially allocated frozen slabs */
#endif
#ifdef CONFIG_SLUB_STATS
unsigned stat[NR_SLUB_STAT_ITEMS];
#endif
};
struct kmem_cache_node：用於管理每個Node的slab頁面，由於每個Node的訪問速度不一致，slab頁面由Node來管理；
/*
* The slab lists for all objects.
*/
struct kmem_cache_node {
spinlock_t list_lock;
#ifdef CONFIG_SLUB
unsigned long nr_partial; //slab頁表數量
struct list_head partial; //slab頁面鏈表
#ifdef CONFIG_SLUB_DEBUG
atomic_long_t nr_slabs;
atomic_long_t total_objects;
struct list_head full;
#endif
#endif
};
struct page：用於描述slab頁面，struct page結構體中很多字段都是通過union聯合體進行復用的。
struct page結構中，用於slub的成員如下：
struct page {
union {
...
void *s_mem; /* slab first object */
...
};
/* Second double word */
union {
...
void *freelist; /* sl[aou]b first free object */
...
};
union {
...
struct {
union {
...
struct { /* SLUB */
unsigned inuse:16;
unsigned objects:15;
unsigned frozen:1;
};
...
};
...
};
};
/*
* Third double word block
*/
union {
...
struct { /* slub per cpu partial pages */
struct page *next; /* Next partial slab */
#ifdef CONFIG_64BIT
int pages; /* Nr of partial slabs left */
int pobjects; /* Approximate # of objects */
#else
short int pages;
short int pobjects;
#endif
};
struct rcu_head rcu_head; /* Used by SLAB
* when destroying via RCU
*/
};
...
struct kmem_cache *slab_cache; /* SL[AU]B: Pointer to slab */
...
}
圖來了：
3. 流程分析
針對Slub的使用，可以從三個維度來分析：
- slub緩存創建
- slub對象分配
- slub對象釋放
下邊將進一步分析。
3.1 kmem_cache_create
在內核中通過kmem_cache_create接口來創建一個slab緩存。
先看一下這個接口的函數調用關系圖：
-
kmem_cache_create完成的功能比較簡單，就是創建一個用於管理slab緩存的kmem_cache結構，並對該結構體進行初始化，最終添加到全局鏈表中。kmem_cache結構體初始化，包括了上文中分析到的kmem_cache_cpu和kmem_cache_node兩個字段結構。 -
在創建的過程中，當發現已有的
slab緩存中，有存在對象大小相近，且具有兼容標志的slab緩存，那就只需要進行merge操作並返回，而無需進一步創建新的slab緩存。 -
calculate_sizes函數會根據指定的force_order或根據對象大小去計算kmem_cache結構體中的size/min/oo等值，其中kmem_cache_order_objects結構體，是由頁面分配order值和對象數量兩者通過位域拼接起來的。 -
在創建
slab緩存的時候，有一個先雞后蛋的問題：kmem_cache結構體來管理一個slab緩存，而創建kmem_cache結構體又是從slab緩存中分配出來的對象，那么這個問題是怎么解決的呢？可以看一下kmem_cache_init函數，內核中定義了兩個靜態的全局變量kmem_cache和kmem_cache_node，在kmem_cache_init函數中完成了這兩個結構體的初始化之后，相當於就是創建了兩個slab緩存，一個用於分配kmem_cache結構體對象的緩存池，一個用於分配kmem_cache_node結構體對象的緩存池。由於kmem_cache_cpu結構體是通過__alloc_percpu來分配的，因此不需要創建一個相關的slab緩存。
3.2 kmem_cache_alloc
kmem_cache_alloc接口用於從slab緩存池中分配對象。
看一下大體的調用流程圖：
從上圖中可以看出，分配slab對象與Buddy System中分配頁面類似，存在快速路徑和慢速路徑兩種，所謂的快速路徑就是per-CPU緩存，可以無鎖訪問，因而效率更高。
整體的分配流程大體是這樣的：優先從per-CPU緩存中進行分配，如果per-CPU緩存中已經全部分配完畢，則從Node管理的slab頁面中遷移slab頁到per-CPU緩存中，再重新分配。當Node管理的slab頁面也不足的情況下，則從Buddy System中分配新的頁面，添加到per-CPU緩存中。
還是用圖來說明更清晰，分為以下幾步來分配：
-
fastpath
快速路徑下，以原子的方式檢索per-CPU緩存的freelist列表中的第一個對象，如果freelist為空並且沒有要檢索的對象，則跳入慢速路徑操作，最后再返回到快速路徑中重試操作。
-
slowpath-1
將per-CPU緩存中page指向的slab頁中的空閑對象遷移到freelist中，如果有空閑對象，則freeze該頁面，沒有空閑對象則跳轉到slowpath-2。
-
slowpath-2
將per-CPU緩存中partial鏈表中的第一個slab頁遷移到page指針中，如果partial鏈表為空，則跳轉到slowpath-3。
-
slowpath-3
將Node管理的partial鏈表中的slab頁遷移到per-CPU緩存中的page中，並重復第二個slab頁將其添加到per-CPU緩存中的partial鏈表中。如果遷移的slab中空閑對象超過了kmem_cache.cpu_partial的一半，則僅遷移slab頁，並且不再重復。
如果每個Node的partial鏈表都為空，跳轉到slowpath-4。
-
slowpath-4
從Buddy System中獲取頁面，並將其添加到per-CPU的page中。
3.2 kmem_cache_free
kmem_cache_free的操作，可以看成是kmem_cache_alloc的逆過程，因此也分為快速路徑和慢速路徑兩種方式，同時，慢速路徑中又分為了好幾種情況，可以參考kmem_cache_alloc的過程。
調用流程圖如下：
效果如下：
-
快速路徑釋放
快速路徑下，直接將對象返回到freelist中即可。
-
put_cpu_partial
put_cpu_partial函數主要是將一個剛freeze的slab頁，放入到partial鏈表中。
在put_cpu_partial函數中調用unfreeze_partials函數，這時候會將per-CPU管理的partial鏈表中的slab頁面添加到Node管理的partial鏈表的尾部。如果超出了Node的partial鏈表，溢出的slab頁面中沒有分配對象的slab頁面將會返回到伙伴系統。
-
add_partial
添加slab頁到Node的partial鏈表中。
-
remove_partial
從Node的partial鏈表移除slab頁。
具體釋放的流程走哪個分支，跟對象的使用情況，partial鏈表的個數nr_partial/min_partial等相關，細節就不再深入分析了。