From: Greg KH <greg@kroah.com>
To: Joel Fuster <j@fuster.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: sysfs_dir_cache growing out of control
Date: Thu, 23 Aug 2007 02:59:33 -0700 [thread overview]
Message-ID: <20070823095933.GA6742@kroah.com> (raw)
In-Reply-To: <46CD057C.3080106@fuster.org>
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?
Oh, and does the same thing happen if you do not use SLUB, but rather
the older SLAB?
>> Although I did not record objective evidence of this at the time, I
>> suspect I had the same problem with 2.6.18 and 2.6.20...I certainly had
>> the same symptoms.
>
> An update to this...it seems to be related to "scanbuttond" which is an app
> that uses libusb to poll a scanner for button presses on the scanner
> itself. The number of objects in sysfs_dir_cache stops growing when I kill
> the scanbuttond process.
>
> 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.
And it looks like a very dumb program, iterating over all usb devices
all the time? You would think that it would not do that, otherwise your
power consumption is going to be very high, and the odds that a new usb
device is going to show up that quickly is pretty low.
thanks,
greg k-h
next prev parent reply other threads:[~2007-08-23 10:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-23 0:25 sysfs_dir_cache growing out of control Joel Fuster
2007-08-23 3:56 ` Joel Fuster
2007-08-23 9:59 ` Greg KH [this message]
2007-08-24 0:44 ` Joel Fuster
2007-08-24 0:54 ` Greg KH
2007-08-24 1:26 ` Gabriel C
2007-09-05 16:03 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070823095933.GA6742@kroah.com \
--to=greg@kroah.com \
--cc=j@fuster.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox