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

-
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/