Messages in this thread | | | Date | Thu, 23 Aug 2007 20:44:10 -0400 | From | Joel Fuster <> | Subject | Re: sysfs_dir_cache growing out of control |
| |
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/
| |