mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Adam J. Richter" <adam@yggdrasil.com>
To: gjwucherpfennig@gmx.net, greg@kroah.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: Kernel thoughts of a Linux user
Date: Mon, 22 Nov 2004 17:54:38 +0800	[thread overview]
Message-ID: <200411220954.iAM9sc002402@freya.yggdrasil.com> (raw)

On 2004-11-18 18:50:11, Greg KH wrote:
>On Thu, Nov 18, 2004 at 06:59:27PM +0100, Gerold J. Wucherpfennig wrote:
>> 
>> - Make sysfs optional and enable to publish kernel <-> userspace data
>> especially the kernel's KObject data across the kernel's netlink interface as
>> it has been summarized on www.kerneltrap.org. This will avoid the
>> deadlocks sysfs does introduce when some userspace app holds an open file
>> handle of an sysfs object (KObject) which is to be removed. An importrant side 
>> effect for embedded systems will be that the RAM overhead introduced by sysfs
>> will vaporize.
>
>What RAM overhead?  With 2.6.10-rc2 the memory footprint of sysfs has
>been drasticly shrunk.

	Looking through 2.6.10-rc2-bk6/fs/sysfs/, it appears to me that
sysfs unswappable memory usage for this desktop system with two
hard disks and a couple of USB devices attached is over 600kB, even
if I do not count the underlying attribute or kobject structures that
are being registered in sysfs.

	Please correct me if I am wrong, but, as far as I can tell,
in 2.6.10-rc2-bk6, a struct dentry is held for each node in the sysfs
tree at all times.  I infer this from noticing that sysfs_drop_dentry
and sysfs_hash_and_remove in fs/sysfs/inode.c only seem to be called
on operations to delete a node.  If I've missed something and the dentry
structures are all or mostly released, I would love to be corrected about
it as that would be really good news to me.

	Here is a partial tally of what I believe are the bytes used for
each sysfs file in the old and new versions (using sizes on my 32-bit
x86 box; your sizes may vary depending on architecture and file system
options that you've enabled).

				Old		New
	dentry			144		144
	inode			344		---
	sysfs_dirent		---		 36
	
	Total			488		180

	There is also an underlying struct attribute (12 bytes) for
sysfs files and struct kobject (52 bytes for sysfs directories), but
let's assume that all of those would still be useful without sysfs.

	The desktop computer on which I am writing this email has
3405 nodes.  So, it's pinned memory consumption has presumbably
dropped from over 1.6 megabytes in the old version to something
over 600kB.

	This is a huge improvement _over the old memory consumption_,
and may also mark the point where most of the rest of the memory
shrink could come from outside of sysfs (for example, by splitting
struct dentry into the part that virtual file systems want to
keep and the part that is only useful when the VFS layer wants
to hold the dentry, or perhaps by making struct dentry and
struct kobject use the same name string), but I would not look at
600kB and say "What RAM overhead?"

	Am I missing something?  Are the dentries being freed
dynamically (for nodes that have not been deleted) in sysfs
in version 2.6.10-rc2-bk6?

                    __     ______________ 
Adam J. Richter        \ /
adam@yggdrasil.com      | g g d r a s i l

             reply	other threads:[~2004-11-22  9:58 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-22  9:54 Adam J. Richter [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-12-14 18:02 Jan Engelhardt
2004-11-22 15:32 Adam J. Richter
2004-11-22 14:54 Adam J. Richter
2004-11-22 20:21 ` Maneesh Soni
2004-11-20 10:31 Gerold J. Wucherpfennig
2004-11-21 18:29 ` Greg KH
2004-11-22 21:33   ` Gerold J. Wucherpfennig
2004-11-22 18:40     ` Greg KH
2004-11-22 18:52     ` Måns Rullgård
2004-11-18 17:59 Gerold J. Wucherpfennig
2004-11-18 18:50 ` Greg KH
2004-11-18 20:00 ` Tomas Carnecky
2004-11-18 20:46   ` Jan Engelhardt
2004-11-18 20:52     ` Tomas Carnecky
2004-11-18 21:05       ` Jan Engelhardt
2004-11-18 21:15     ` Chris Friesen
2004-11-18 21:17       ` Jan Engelhardt
2004-11-18 21:29         ` Chris Friesen
2004-11-19 12:02         ` Paulo Marques
2004-11-19 12:05           ` Jan Engelhardt
2004-11-20  2:14           ` Alan Cox
2004-11-22  8:07   ` Helge Hafting
2004-11-22  8:38     ` Jan Engelhardt
2004-11-24 10:23       ` Helge Hafting
2004-11-22 11:17     ` Tomas Carnecky
2004-11-24 10:20       ` Helge Hafting
2004-11-24 11:31         ` Tomas Carnecky
2004-11-28 19:10           ` Helge Hafting
2004-11-19  5:04 ` H. Peter Anvin

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=200411220954.iAM9sc002402@freya.yggdrasil.com \
    --to=adam@yggdrasil.com \
    --cc=gjwucherpfennig@gmx.net \
    --cc=greg@kroah.com \
    --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

all inboxes | Powered by JetHome®