All of lore.kernel.org
 help / color / mirror / Atom feed
From: khali@linux-fr.org (Jean Delvare)
To: lm-sensors@vger.kernel.org
Subject: [lm-sensors] [PATCH] Add voltage support to W83627EHF
Date: Thu, 09 Mar 2006 20:21:56 +0000	[thread overview]
Message-ID: <20060309212156.dac64387.khali@linux-fr.org> (raw)
In-Reply-To: <4409700D.8010604@sh.cvut.cz>

Hi Greg,

> > The only data I am missing now is the memory used by each additional
> > sysfs file we create. We need to know, as Hans objected that too many
> > sysfs files could have a negative impact on memory consumption. I dug
> > down the sysfs code yeterday evening to find out, but didn't find what
> > I was looking for yet. I hope to get the answer this evening.
> 
> sysfs files are very light.  The "large" memory structures for a ram
> based file system are the dentry and inode structures.  sysfs now
> creates them on the fly when they are needed, and if we have memory
> pressure on our internal kernel caches, they are freed.
> 
> So in short, don't worry about creating new sysfs files, it's not an
> issue.  The people running 20,000 disks on a 31bit s390 system have
> already done the hard work for you :)

Thanks for your enlightened comment on this. Now, this still raises the
question of how much the dentry and inode structures take. You say that
they are created on the fly, but let's imagine a hardware monitoring
utility polling the sysfs files on a regular basis, I guess that these
structures could be considered as "permanently allocated" for this set
of sysfs files, so the dentry and inode sizes would start to matter.

From /proc/slabinfo, I get the following sizes:
x86: dentry 124 bytes, inode 336 bytes
x86_64: dentry 200 bytes, inode 608 bytes

For 33 additional files, counting one of each structure per file (which
might not be correct, I'm really ignorant of how it actually works),
it's around 17 kB on x86 and 29 kB on x86_64. While still not
unacceptable (IMHO at least), this is much more than my first
estimation.

Thanks,
-- 
Jean Delvare


  parent reply	other threads:[~2006-03-09 20:21 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-04 10:46 [lm-sensors] [PATCH] Add voltage support to W83627EHF Rudolf Marek
2006-03-04 12:41 ` Rudolf Marek
2006-03-04 15:04 ` Jean Delvare
2006-03-04 16:57 ` Jean Delvare
2006-03-07 20:02 ` Rudolf Marek
2006-03-07 20:03 ` Rudolf Marek
2006-03-08 12:58 ` Jean Delvare
2006-03-08 13:13 ` Jean Delvare
2006-03-08 16:48 ` David Hubbard
2006-03-09 16:09 ` Greg KH
2006-03-09 20:21 ` Jean Delvare [this message]
2006-03-09 23:54 ` Greg KH
2006-03-23 22:08 ` Rudolf Marek
2006-03-23 23:09 ` David Hubbard
2006-03-24  4:04 ` David Hubbard
2006-03-24  6:01 ` David Hubbard

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=20060309212156.dac64387.khali@linux-fr.org \
    --to=khali@linux-fr.org \
    --cc=lm-sensors@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 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.