From: Dipankar Sarma <dipankar@in.ibm.com>
To: Greg KH <greg@kroah.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 23:31:19 +0530 [thread overview]
Message-ID: <20031006180119.GC1788@in.ibm.com> (raw)
In-Reply-To: <20031006173858.GA4403@kroah.com>
On Mon, Oct 06, 2003 at 10:38:58AM -0700, Greg KH wrote:
> On Mon, Oct 06, 2003 at 11:01:11PM +0530, Dipankar Sarma wrote:
> > 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?
Sure. At the same time, as Maneesh pointed out, this is just an
RFC. The backing store design probably needs quite some work first.
> > --------------------------------------------------------
> > 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 :)
That would not happen in a normal running system often, right ? So,
I don't see the point looking at mem usage after hotplug events.
>
> > 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?
It should be easy to demonstrate. That is how dentries/inodes
work for on-disk filesystems. If Maneesh's patch didn't work that
way, then the whole point is lost. I hope that is not the case.
>
> > 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.)
IIRC, Maneesh test machine is a 2-way P4 xeon with six scsi disks and savings
are of about 800KB. That is as normal a case as it gets, I think.
It only gets better as you have more devices in your system.
Thanks
Dipankar
next prev parent reply other threads:[~2003-10-06 17:59 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
2003-10-06 18:01 ` Dipankar Sarma [this message]
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=20031006180119.GC1788@in.ibm.com \
--to=dipankar@in.ibm.com \
--cc=greg@kroah.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.