Re: sysfs_dir_cache growing out of control

Joel Fuster
2007-08-24T00:44:39Z

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