slab源码分析--kmalloc函数分析

这次来说一个关键函数，kmalloc()函数。
 

函数原型

#include Linux/slab.h> 
void *kmalloc(size_t size, int flags); 

size是要分配内存的大小，不过内核会对大小进行适配，比如取32，64等等，是和缓存行等体系结构有关系的，总之可能会比你要申请的内存大一些。
flags是与伙伴系统交互的标记，虽说kmalloc()是从slab分配内存，不过底层还是要和伙伴系统交互的。

我们来看一下这些标记：

flags	含义
GFP_ATOMIC	用来从中断处理和进程上下文之外的其他代码中分配内存，从不睡眠
GFP_KERNEL	内核内存的正常分配，可能睡眠
GFP_USER	用来为用户空间页分配内存，可能睡眠
GFP_HIGHUSER	类似GPR_USER，但是是从高端内存分配。
GFP_NOIO	类似GFP_KERNEL，禁止任何文件系统调用
GFP_NOFD	类似GFP_KERNEL，禁止任何I/O初始化

 
上面这些标志底层是组合了下面这些标志实现的：
__GFP_DMA
这个标志要求分配在能够 DMA 的内存区. 确切的含义是平台依赖的并且在下面章节来解释.
__GFP_HIGHMEM
这个标志指示分配的内存可以位于高端内存.
__GFP_COLD
正常地, 内存分配器尽力返回”缓冲热”的页 – 可能在处理器缓冲中找到的页. 相反, 这个标志请求一个”冷”页, 它在一段时间没被使用. 它对分配页作 DMA 读是有用的, 此时在处理器缓冲中出现是无用的. 一个完整的对如何分配 DMA 缓存的讨论看”直接内存存取”一节在第 1 章.
__GFP_NOWARN
这个很少用到的标志阻止内核来发出警告(使用 printk ), 当一个分配无法满足.
__GFP_HIGH
这个标志标识了一个高优先级请求, 它被允许来消耗甚至被内核保留给紧急状况的最后的内存页.
__GFP_REPEAT
__GFP_NOFAIL
__GFP_NORETRY
这些标志修改分配器如何动作, 当它有困难满足一个分配. __GFP_REPEAT 意思是” 更尽力些尝试” 通过重复尝试 – 但是分配可能仍然失败. __GFP_NOFAIL 标志告诉分配器不要失败; 它尽最大努力来满足要求. 使用 __GFP_NOFAIL 是强烈不推荐的; 可能从不会有有效的理由在一个设备驱动中使用它. 最后, __GFP_NORETRY 告知分配器立即放弃如果得不到请求的内存.
 

源码剖析

直接看kmalloc函数：

static inline void *kmalloc(size_t size, gfp_t flags)
{
    if (__builtin_constant_p(size)) {
        int i = 0;
#define CACHE(x) \
        if (size <= x) \
            goto found; \
        else \
            i++;
#include "kmalloc_sizes.h"
#undef CACHE
        {
            extern void __you_cannot_kmalloc_that_much(void);
            __you_cannot_kmalloc_that_much();
        }
found:
#ifdef CONFIG_ZONE_DMA
        if (flags & GFP_DMA)
            return kmem_cache_alloc(malloc_sizes[i].cs_dmacachep,
                        flags);
#endif
        return kmem_cache_alloc(malloc_sizes[i].cs_cachep, flags);
    }
    return __kmalloc(size, flags);
}

首先在本函数中手动确定要申请的内存大小，(1) 如果成功就跳至found，执行kmem_cache_alloc()，因为它的大小已经找到。kmem_cache_alloc()底层转调用__cache_alloc()函数。(2) 如果不成功，执行__kmalloc()函数，而__kmalloc()函数底层也是会适配大小的，它的调用关系为__kmalloc()->__do_kmalloc()，然后在__do_kmalloc()函数中会执行__find_general_cachep()，这个函数也是用来手动确定大小的函数，大小确定后调用__cache_alloc()函数。所以两种情况最终都会确定要分配内存的大小，交由__cache_alloc()函数执行分配工作。

大小是怎么确定的？参见我先前的博客： slab源码分析–从slab初始化说起

不过这里还是要提一下，关于大小的一点小知识，首先看kmalloc_sizes.h中的定义：

#if (PAGE_SIZE == 4096)
    CACHE(32)
#endif
    CACHE(64)
#if L1_CACHE_BYTES < 64
    CACHE(96)
#endif
    CACHE(128)

注意这一句，#IF L1_CACHE_BYTES < 64，CACHE(96)，也就是说如果缓存行大小大于等于64，就不会分配96字节的内存，而是直接到128。因为96-64=32小于缓存行的大小64。从这里可以看出，如果一页大小是4K，那么最小分配的内存大小是32字节，其他允许分配的内存大小还可能取决于缓存行的大小。

由于kmalloc()底层调用__cache_alloc()函数，这是它和kmem_cache_create()函数公共的接口，我在之前博客 slab源码分析–从slab初始化说起已经说过了，就不必细说了。