lkml.org 
[lkml]   [2001]   [Oct]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectSlab Allocator Leak?
Date
I have a script (below) which creates a file, deletes it, and loops.  In
/proc/slabinfo, I see many dentry_cache slabs being created - to the point
where nearly all free memory is consumed. The system is still usable, as
the slab allocator responds to memory pressure and releases some of these
dentry_cache slabs.

If I understand the USENIX paper correctly, a single dentry_cache slab
buffer should be sufficient for my case, as the system will reuse that
buffer for the new dentry.

Furthermore, this memory consumption only occurs with different filenames.
If I simply do a "while [ 1 ] ; do touch myfile ; rm myfile ; done", the
extra dentry_cache slabs do not get created.

I've been able to reproduce this under 2.4.2, 2.4.9, 2.4.13, and someone
else confirmed they saw this behavior under 2.4.13-ac3.

Thanks.


Vijay Gadad
vgadad@zantaz.com


-----CUT-----
#!/bin/sh

COUNTER=2000000000

while [ $COUNTER -gt 0 ]
do
touch testfile.$COUNTER
rm -f testfile.$COUNTER
COUNTER=`expr $COUNTER - 1`
done
-----CUT-----


# cat /proc/slabinfo
slabinfo - version: 1.1
kmem_cache 54 78 100 2 2 1
tcp_tw_bucket 0 0 96 0 0 1
tcp_bind_bucket 29 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 10 113 32 1 1 1
ip_dst_cache 14 24 160 1 1 1
arp_cache 3 30 128 1 1 1
blkdev_requests 256 280 96 7 7 1
dnotify cache 0 0 20 0 0 1
file lock cache 2 42 92 1 1 1
fasync cache 0 0 16 0 0 1
uid_cache 2 113 32 1 1 1
skbuff_head_cache 54 72 160 3 3 1
sock 82 90 832 10 10 2
sigqueue 1 29 132 1 1 1
cdev_cache 495 826 64 12 14 1
bdev_cache 6605 6962 64 114 118 1
mnt_cache 14 59 64 1 1 1
inode_cache 10809 13632 480 1703 1704 1
dentry_cache 253205 253230 128 8441 8441 1
filp 553 560 96 14 14 1
names_cache 0 7 4096 0 7 1
buffer_head 42229 42280 96 1056 1057 1
mm_struct 29 48 160 2 2 1
vm_area_struct 772 1062 64 14 18 1
fs_cache 28 59 64 1 1 1
files_cache 28 36 416 4 4 1
signal_act 32 33 1312 11 11 1
size-131072(DMA) 0 0 131072 0 0 32
size-131072 0 0 131072 0 0 32
size-65536(DMA) 0 0 65536 0 0 16
size-65536 0 0 65536 0 0 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 0 0 8192 0 0 2
size-4096(DMA) 0 0 4096 0 0 1
size-4096 75 76 4096 75 76 1
size-2048(DMA) 0 0 2048 0 0 1
size-2048 38 42 2048 20 21 1
size-1024(DMA) 0 0 1024 0 0 1
size-1024 25 28 1024 7 7 1
size-512(DMA) 0 0 512 0 0 1
size-512 29 32 512 4 4 1
size-256(DMA) 0 0 256 0 0 1
size-256 8 15 256 1 1 1
size-128(DMA) 0 0 128 0 0 1
size-128 439 450 128 15 15 1
size-64(DMA) 0 0 64 0 0 1
size-64 114 236 64 3 4 1
size-32(DMA) 0 0 32 0 0 1
size-32 251432 261595 32 2226 2315 1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:12    [W:0.043 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site