All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <haveblue@us.ibm.com>
To: "Hariprasad Nellitheertha [imap]" <hari@in.ibm.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	fastboot <fastboot@lists.osdl.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Andrew Morton <akpm@osdl.org>
Subject: Re: [RFC] Obtaining memory information for kexec/kdump
Date: Thu, 24 Mar 2005 07:32:51 -0800	[thread overview]
Message-ID: <1111678371.9881.46.camel@localhost> (raw)
In-Reply-To: <4242941A.3050501@in.ibm.com>

On Thu, 2005-03-24 at 15:49 +0530, Hariprasad Nellitheertha wrote:
> Dave Hansen wrote:
> > I think there's likely a lot of commonality with the needs of memory
> > hotplug systems here.  We effectively dump out the physical layout of
> > the system, but in sysfs.  We do this mostly because any memory hotplug
> > changes generate hotplug events, just like all other hardware.  If you
> > do this in /proc, it's another thing that memory hotplug will have to
> > update.  
> 
> We put it in /proc primarily because what we wanted was 
> similar in many ways to /proc/iomem and so we (re)use a bit 
> of the code.

The code reuse is nice, but the expanded use of /proc is not.  

> Also, we were wondering if it is appropriate to 
> put in multiple values in a single file in sysfs.

Why would you need to do that?
>   I've attached a document I started writing a couple days ago
> > about the sysfs layout and the call paths for hotplug.  It's horribly
> > incomplete, but not a bad start.
> > 
> > If you want to see some more details of the layout, please check out
> > this patch set:
> > 
> > http://www.sr71.net/patches/2.6.12/2.6.12-rc1-mhp1/patch-2.6.12-rc1-mhp1.gz
> 
> This does not have the sysfs related code. Is there a 
> separate patch for adding the sysfs entries?

Hmmm.  I think my rollup script broke.  Try this:

http://www.sr71.net/patches/2.6.12/2.6.12-rc1-mhp1/broken-out/L0-sysfs-memory-class.patch

> > block_size_bytes:  The size of each memory section (in hex)
> 
> This value is per memoryXXXX directory, right?

No, it's global.  However, we have discussed doing it per-section in the
future to collapse some of the contiguous areas into a single directory.

-- Dave


  reply	other threads:[~2005-03-24 15:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-24  5:49 [RFC] Obtaining memory information for kexec/kdump Hariprasad Nellitheertha
2005-03-24  5:52 ` [RFC][PATCH 1/7] Converting resource struct fields to 64 bit Hariprasad Nellitheertha
2005-03-24  5:53   ` [RFC][PATCH 2/7] Common code for the physmem map Hariprasad Nellitheertha
2005-03-24  5:55     ` [RFC][PATCH 3/7] i386 " Hariprasad Nellitheertha
2005-03-24  5:56       ` [RFC][PATCH 4/7] x86_64 " Hariprasad Nellitheertha
2005-03-24  5:57         ` [RFC][PATCH 5/7] Common code for the activemem map Hariprasad Nellitheertha
2005-03-24  5:58           ` [RFC][PATCH 6/7] i386 " Hariprasad Nellitheertha
2005-03-24  6:00             ` [RFC][PATCH 7/7] x86_64 " Hariprasad Nellitheertha
2005-03-24  7:50 ` [RFC] Obtaining memory information for kexec/kdump Dave Hansen
2005-03-24 10:19   ` Hariprasad Nellitheertha
2005-03-24 15:32     ` Dave Hansen [this message]
2005-03-28 13:00       ` Hariprasad Nellitheertha
2005-03-28 16:18         ` Dave Hansen

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=1111678371.9881.46.camel@localhost \
    --to=haveblue@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=ebiederm@xmission.com \
    --cc=fastboot@lists.osdl.org \
    --cc=hari@in.ibm.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 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.