Re: sysfs_dir_cache growing out of control

[Joel Fuster <j@fuster.org>]

Greg KH wrote:
> On Wed, Aug 22, 2007 at 11:56:44PM -0400, Joel Fuster wrote:
>> Joel Fuster wrote:
>>> Hi,
>>> I am running 2.6.22.3.  For reasons that escape me, over time (days) the 
>>> sysfs_dir_cache, dentry, and inode_cache SLUB entries grow until they 
>>> consume all the memory on my system, requiring a reboot.
> 
> Hm, those items should consume all the memory, but it should be freed if
> you have memory pressure from other places.  Does it cause the machine
> to lock up, or you just got scared when seeing them?
> 
Right.  The problem is that the memory never seems to get freed no 
matter what I do.  I've tried setting /proc/sys/vm/vfs_cache_pressure to 
10000, but after a few days all my programs are running out of swap and 
I have to reboot to get things back to a usable state.

> Oh, and does the same thing happen if you do not use SLUB, but rather
> the older SLAB?

OK I just rebuilt 2.6.22.3 with SLAB and I seem to be getting the same 
result..obviously I haven't waited several days, but 
sysfs_dir_cache/dentry/inode_cache grow continuously when scanbuttond is 
running, and stop growing when it isn't.


>>
>> An strace of one poll loop for scanbuttond follows:
>>
>>
>> nanosleep({0, 333000000}, NULL)         = 0
>> open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 1
>> fstat(1, {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
>> fcntl(1, F_SETFD, FD_CLOEXEC)           = 0
>> getdents(1, /* 4 entries */, 4096)      = 96
>> getdents(1, /* 0 entries */, 4096)      = 0
>> close(1)                                = 0
>> open("/dev/bus/usb/002", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 1
>> fstat(1, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0
>> fcntl(1, F_SETFD, FD_CLOEXEC)           = 0
>> getdents(1, /* 3 entries */, 4096)      = 72
>> open("/dev/bus/usb/002/001", O_RDWR)    = -1 EACCES (Permission denied)
>> open("/dev/bus/usb/002/001", O_RDONLY)  = 2
>> ioctl(2, USBDEVFS_CONNECTINFO, 0x7fffb3a08420) = -1 EPERM (Operation not 
>> permitted)
> 
> <snip>
> 
> I don't see any sysfs accesses there, only usbfs accesses.

Yes, I don't know enough to understand why this would affect 
sysfs_dir_cache, but there definitely seems to be a connection.

Thanks for the help,

Joel