问一个关于slabinfo的问题

chenrvmldd

最近在研究Linux2.4.25的内核发现一个奇怪的问题：在我的板子上我发现内核初始化后占用的内存非常大：
/ # free
                    total         used         free       shared      buffers
  Mem:        13964        12404         1560            0            0
Swap:            0            0            0
Total:        13964        12404         1560
/ # cat /proc/meminfo  
        total:    used:    free:  shared: buffers:  cached:
Mem:  14299136 12709888  1589248        0        0  1941504
Swap:        0        0        0
MemTotal:        13964 kB
MemFree:          1552 kB
MemShared:           0 kB
Buffers:             0 kB
Cached:           1896 kB
SwapCached:          0 kB
Active:            428 kB
Inactive:         1716 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:        13964 kB
LowFree:          1552 kB
SwapTotal:           0 kB
SwapFree:            0 kB
从上面内存打印出的信息，可以看出剩余的内存只有1560K，剩余的内存太小了，后来经过仔细的分析，我发现我的系统中slab占用内存太多了：
/ # cat /proc/slabinfo
slabinfo - version: 1.1
kmem_cache            65     72    108    2    2    1
tcp_tw_bucket          0      0     96    0    0    1
tcp_bind_bucket        2    113     32    1    1    1
tcp_open_request       0      0     64    0    0    1
inet_peer_cache        0      0     64    0    0    1
ip_fib_hash            5    113     32    1    1    1
ip_dst_cache           0      0    160    0    0    1
arp_cache              0      0     96    0    0    1
blkdev_requests      512    520     96   13   13    1
jffs2_inode_cache    458    580     24    4    4    1
jffs2_node_frag      591   1890     28    5   15    1
jffs2_raw_node_ref   2928   3030     16   15   15    1
jffs2_tmp_dnode        0   1518     12    0    6    1
jffs2_raw_inode        0     56     68    0    1    1
jffs2_raw_dirent       0      0     40    0    0    1
jffs2_full_dnode     622   2020     16    4   10    1
nfs_write_data         0      0    384    0    0    1
nfs_read_data          0      0    352    0    0    1
nfs_page               0      0     96    0    0    1
dnotify_cache          0      0     20    0    0    1
file_lock_cache        0      0     96    0    0    1
fasync_cache           0      0     16    0    0    1
uid_cache              0      0     32    0    0    1
skbuff_head_cache   2048   2064    160   86   86    1
sock                   6     10    768    2    2    1
sigqueue               0     29    132    0    1    1
kiobuf                 0      0     64    0    0    1
cdev_cache             4    113     32    1    1    1
bdev_cache             2     59     64    1    1    1
mnt_cache              9     59     64    1    1    1
inode_cache           64     64    480    8    8    1
dentry_cache          82     90    128    3    3    1
filp                  12     30    128    1    1    1
names_cache            0      2   4096    0    2    1
buffer_head            0      0     96    0    0    1
mm_struct              5     30    128    1    1    1
vm_area_struct        21     40     96    1    1    1
fs_cache               4    113     32    1    1    1
files_cache            5      9    416    1    1    1
signal_act             8      9   1312    3    3    1
size-131072(DMA)       0      0 131072    0    0   32
size-131072            0      1 131072    0    1   32
size-65536(DMA)        0      0  65536    0    0   16
size-65536             3      3  65536    3    3   16
size-32768(DMA)        0      0  32768    0    0    8
size-32768             0      0  32768    0    0    8
size-16384(DMA)        0      0  16384    0    0    4
size-16384             0      0  16384    0    0    4
size-8192(DMA)         0      0   8192    0    0    2
size-8192              2      2   8192    2    2    2
size-4096(DMA)         0      0   4096    0    0    1
size-4096           2055   2055   4096 2055 2055    1
size-2048(DMA)         0      0   2048    0    0    1
size-2048              7      8   2048    4    4    1
size-1024(DMA)         0      0   1024    0    0    1
size-1024             12     16   1024    3    4    1
size-512(DMA)          0      0    512    0    0    1
size-512               9     16    512    2    2    1
size-256(DMA)          0      0    256    0    0    1
size-256               5     15    256    1    1    1
size-128(DMA)          0      0    128    0    0    1
size-128             847    870    128   29   29    1
size-64(DMA)           0      0     64    0    0    1
size-64              159    177     64    3    3    1
size-32(DMA)           0      0     32    0    0    1
size-32             2531   2599     32   23   23    1

大家注意看一下size-4096这一项，有2055个SLAB，每个SLAB占用4K的内存，那么2055*4=8M左右了，这个占用太大了，想请高手帮忙分析一下，为什么size-4096占用这么大的内存了？
能不能通过某种方法找出到底是哪些东西在占用size-4096？注明一下，系统此时没有跑任何的应用程序，系统初始化完毕就是这样的状态

iceyes342

回复 1# chenrvmldd


    我也碰到类似的问题了。你的问题解决了吗。请问，size-4096这些对象是做什么用的？kmalloc?

chenrvmldd

回复 2# iceyes342

我找到了，是别人的代码导致的，呵呵
   

unbutun

什么设备内存这么小

wy174828162

请问一下是别人什么代码导致的。我也遇到类似的情况。遍历一个路径下的所有文件。如果路径下面有好多文件就导致freebuffer减少slab数据增加。不知道为什么？回复 3# chenrvmldd


   

action08

回复 4# unbutun


    智能小设备，不是纯计算机环境哦亲

7863612

我最近也发现了这个问题，环境是嵌入式linux，64M内存，slab数据中SUnreclaim数据一上来就很高大概在30m左右，求解，楼主应用程序出现了什么问题？别的程序内存泄漏？回复 3# chenrvmldd