skbuff_head_cache去哪里了



在定位linux网络系统内存使用相关问题的时候，/proc/slabinfo下的"skbuff_head_cache"和"skbuff_fclone_cache"是常用的工具，但是有时候你会发现在/proc/slabinfo没有这两个条目，本文记录了其原因以及如何确认对应的sk_buffer结构的大致数量。

         如何找到对应的slabinfo

找不到"skbuff_head_cache"和"skbuff_fclone_cache"的原因是在CONFIG_SLUB这个配置下，memory
cache可能被合并使用。

 

访问/sys/kernel/slab/xxx，xxx为要找的slabinfo的名称，在这个目录下可以看到该slab所共用的memory
cache的信息(各个共用该slab的memory
cache的统计数据之和)。

 

找到所有的共用者的方法：在/sys/kernel/slab目录使用”ll
| grep xxx”，你会看到要找的slabinfo被链接到一个目录，名为”:t-xxx”(其中xxx为该slab大小)，这个目录对应的就是真实的slabinfo，通过ll命令查看有哪些slab链接到该目录(:t-0000512这种)，这些目录对应的就是共用该kmem_cache结构的所有memory
cache(他们中的一个会出现在/proc/slabinfo中，查看对应的目录也可以得到相关信息)。

         相关内核实现

首先确认你的系统编译的时候，打开的是CONFIG_SLUB这个选项，CONFIG_SLAB和CONFIG_SLOB不会存在这个问题。

在打开了CONFIG_SLUB的情况下，内核在创建memory cache结构的时候，会先看能否使用已有的struct kmem_cache结构，而不是对每次kmem_cache_create都生成独立的struct
kmem_cache结构，这就造成了很多kmem_cache_create调用其实没有生成struct kmem_cache结构，在/proc/slabinfo中也就看不到了。具体如下：

内核初始化的时候skb_init调用kmem_cache_create来创建"skbuff_head_cache"和"skbuff_fclone_cache"这两个memory
cache，其执行的是mm/slub.c中定义的kmem_cache_create函数，看看该函数的实现就清楚了(其先通过find_mergeable看看有无现成的可以结构)。

内核相关实现在kmem_cache_create->sysfs_slab_alias这个函数中完成，分析这个函数可以知道虽然共用了structkmem_cache结构，每次kmem_cache_create调用的时候，会在/sys/kernel/slab目录下用调用者提供的name创建一个目录，并把该目录链接到其共用的struct
kmem_cache结构对应的目录结构中。

slabinfo对应的proc目录名称命名方式见内核函数sysfs_slab_add，其命名方式为：对于unmergeable(具体条件见内核函数slab_unmergeable)的，直接使用kmem_cache_create调用传入的名字，否则使用create_unique_id创建有类型、大小决定的名字。