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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
