Most recent kernel where this bug did not occur: Distribution: Debian GNU/Linux Hardware Environment: Toshiba laptop Software Environment: Linux Problem Description: I found that my system swap a lot after one day of use. Looks like the kernel is not freeing the memory it allocates. I join to this bug /proc/meminfo, /proc/slabinfo, and an output of the slabtop command. I already had this problem with older kernel, but I can't tell you precisely which version. Steps to reproduce: Boot Linux, and make lot of filesystem activities (ls -lR /, debootstrap). My fs is ext3. Then, slab memory in /proc/meminfo never stop to grow.
Created attachment 5789 [details] /proc/meminfo output
Created attachment 5790 [details] /proc/slabinfo output
Created attachment 5791 [details] slabtop output
Created attachment 5792 [details] mount command output
Created attachment 5793 [details] dmesg command output
Are you using htree, or quotas, or extented attributes?
Not at all. Here are the EXT3 related parameters for the kernel I use (stock Debian kernel package with no tuning/tweaking): CONFIG_EXT3_FS=m CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y
Still, you might be using htree. Please do dumpe2fs -h /dev/hdXX
% /sbin/dumpe2fs -h /dev/hda3 dumpe2fs 1.38 (30-Jun-2005) Filesystem volume name: <none> Last mounted on: <not available> Filesystem UUID: 4492d861-424d-4235-8e70-a962cf3ec465 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal filetype needs_recovery sparse_super Default mount options: (none) Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 1889408 Block count: 3777283 Reserved block count: 188864 Free blocks: 286175 Free inodes: 1593822 First block: 0 Block size: 4096 Fragment size: 4096 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 16288 Inode blocks per group: 509 Filesystem created: Sat Nov 8 20:24:23 2003 Last mount time: Mon Aug 29 01:36:51 2005 Last write time: Mon Aug 29 01:36:51 2005 Mount count: 11 Maximum mount count: 36 Last checked: Sat Aug 13 00:01:46 2005 Check interval: 15552000 (6 months) Next check after: Wed Feb 8 23:01:46 2006 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 128 Journal inode: 8 First orphan inode: 863293 Default directory hash: tea Directory Hash Seed: 04e57526-b551-43e1-9c9c-42d5f4e61935 Journal backup: inode blocks
OK, no htree. Weird, beats me. Could you please run a -mm kernel (say, 2.6.13-rc6-mm2) which contains slab-leak-detector.patch and follow the instructions in ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc6/2.6.13-rc6-mm2/broken-out/slab-leak-detector.patch ? (Or just apply slab-leak-detector.patch to your favourite kernel)
Hi, sorry for the lag, but I was on vacation. I installed and runned a 2.6.13-rc6-mm2, and with this kernel I have no more slab leaks ! I tried to patch my Debian 2.6.12 kernel with the slab-leak-detector.patch, but the patch doesn't apply really well.
I had this bug with 2.6.13, but it seems it is fixed in 2.6.14 :) I close the bug. Regards,