From: Greg KH <greg@kroah.com>
To: Dipankar Sarma <dipankar@in.ibm.com>
Cc: Maneesh Soni <maneesh@in.ibm.com>,
Al Viro <viro@parcelfarce.linux.theplanet.co.uk>,
Patrick Mochel <mochel@osdl.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC 0/6] Backing Store for sysfs
Date: Mon, 6 Oct 2003 10:38:58 -0700 [thread overview]
Message-ID: <20031006173858.GA4403@kroah.com> (raw)
In-Reply-To: <20031006173111.GA1788@in.ibm.com>
On Mon, Oct 06, 2003 at 11:01:11PM +0530, Dipankar Sarma wrote:
> On Mon, Oct 06, 2003 at 09:08:46AM -0700, Greg KH wrote:
> > On Mon, Oct 06, 2003 at 02:29:15PM +0530, Maneesh Soni wrote:
> > >
> > > 2.6.0-test6 With patches.
> > > -----------------
> > > dentry_cache (active) 2520 2544
> > > inode_cache (active) 1058 1050
> > > LowFree 875032 KB 874748 KB
> >
> > So with these patches we actually eat up more LowFree if all sysfs
> > entries are searched, and make the dentry_cache bigger? That's not good :(
>
> My guess is that those 24 dentries are just noise. What we should
> do is verify with a large number of devices if the numbers are all
> that different after a walk of the sysfs tree.
Ok, a better test would be with a _lot_ of devices. Care to test with a
lot of scsi debug devices?
> > Remember, every kobject that's created will cause a call to
> > /sbin/hotplug which will cause udev to walk the sysfs tree to get the
> > information for that kobject. So I don't see any savings in these
> > patches, do you?
>
> Assuming that unused files/dirs are aged out of dentry and inode cache,
> it should benefit. The numbers you should look at are -
>
> --------------------------------------------------------
> After mounting sysfs
> -------------------
> dentry_cache (active) 2350 1321
> inode_cache (active) 1058 31
> LowFree 875096 KB 875836 KB
> --------------------------------------------------------
>
> That saves ~800KB. If you just mount sysfs and use a few files, you
> aren't eating up dentries and inodes for every file in sysfs. How often
> do you expect hotplug events to happen in a system ?
Every kobject that is created and is associated with a subsystem
generates a hotplug call. So that's about every kobject that we care
about here :)
> Some time after a hotplug event, dentries/inodes will get aged out and
> then you should see savings. It should greatly benefit in a normal
> system.
Can you show this happening?
> Now if the additional kobjects cause problems with userland hotplug, then
> that needs to be resolved. However that seems to be a different problem
> altogether. Could you please elaborate on that ?
No, I don't think the additional ones you have added will cause
problems, but can you verify this? Just log all hotplug events
happening in your system (point /proc/sys/kernel/hotplug to a simple
logging program).
But again, I don't think the added overhead you have added to a kobject
is acceptable for not much gain for the normal case (systems without a
zillion devices.)
thanks,
greg k-h
next prev parent reply other threads:[~2003-10-06 17:39 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-06 8:59 [RFC 0/6] Backing Store for sysfs Maneesh Soni
2003-10-06 9:00 ` [RFC 1/6] sysfs-kobject.patch Maneesh Soni
2003-10-06 9:00 ` [RFC 2/6] sysfs-mount.patch Maneesh Soni
2003-10-06 9:01 ` [RFC 3/6] sysfs-file.patch Maneesh Soni
2003-10-06 9:01 ` [RFC 4/6] sysfs-symlink.patch Maneesh Soni
2003-10-06 9:02 ` [RFC 5/6] sysfs-attr_group.patch Maneesh Soni
2003-10-06 9:03 ` [RFC 6/6] sysfs-dir.patch Maneesh Soni
2003-10-06 13:43 ` [RFC 2/6] sysfs-mount.patch viro
2003-10-07 7:17 ` Maneesh Soni
2003-10-06 13:41 ` [RFC 1/6] sysfs-kobject.patch viro
2003-10-06 16:16 ` Greg KH
2003-10-06 17:41 ` Dipankar Sarma
2003-10-06 17:44 ` Greg KH
2003-10-06 16:08 ` [RFC 0/6] Backing Store for sysfs Greg KH
2003-10-06 17:31 ` Dipankar Sarma
2003-10-06 17:38 ` Greg KH [this message]
2003-10-06 18:01 ` Dipankar Sarma
2003-10-06 18:09 ` Greg KH
2003-10-06 18:31 ` Dipankar Sarma
2003-10-06 18:34 ` Greg KH
2003-10-07 9:08 ` Andreas Jellinghaus
2003-10-06 18:44 ` Patrick Mochel
2003-10-06 19:27 ` Dipankar Sarma
2003-10-06 19:30 ` viro
2003-10-06 20:01 ` Dipankar Sarma
2003-10-06 20:34 ` viro
2003-10-07 4:47 ` Maneesh Soni
2003-10-06 19:33 ` Patrick Mochel
2003-10-06 20:26 ` Dipankar Sarma
2003-10-06 20:29 ` Patrick Mochel
2003-10-07 4:31 ` Maneesh Soni
2003-10-07 5:25 ` Nick Piggin
2003-10-07 7:17 ` Maneesh Soni
-- strict thread matches above, loose matches on Subject: below --
2003-10-06 12:34 Christian Borntraeger
2003-10-06 17:38 Christian Borntraeger
2003-10-06 17:41 ` Greg KH
2003-10-06 18:00 ` Kevin P. Fleming
2003-10-06 18:11 ` Greg KH
2003-10-06 18:23 ` Kevin P. Fleming
2003-10-06 18:30 ` Greg KH
2003-10-06 18:38 ` Kevin P. Fleming
2003-10-07 8:30 ` Maneesh Soni
2003-10-06 18:19 Christian Borntraeger
[not found] <Dzxw.1wW.3@gated-at.bofh.it>
[not found] ` <DGfG.4UY.3@gated-at.bofh.it>
[not found] ` <DHv1.5Ir.1@gated-at.bofh.it>
[not found] ` <DHEU.7ET.19@gated-at.bofh.it>
[not found] ` <DHY6.3c0.7@gated-at.bofh.it>
[not found] ` <DI7S.58w.13@gated-at.bofh.it>
2003-10-06 19:01 ` Pascal Schmidt
2003-10-06 19:10 ` Greg KH
2003-10-07 0:15 ` Pascal Schmidt
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=20031006173858.GA4403@kroah.com \
--to=greg@kroah.com \
--cc=dipankar@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maneesh@in.ibm.com \
--cc=mochel@osdl.org \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.