Re: [RFC] Obtaining memory information for kexec/kdump

From: Hariprasad Nellitheertha
Date: Thu Mar 24 2005 - 05:24:00 EST


Dave Hansen wrote:
On Thu, 2005-03-24 at 11:19 +0530, Hariprasad Nellitheertha 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. Also, we were wondering if it is appropriate to put in multiple values in a single file in sysfs.


Also, we already have a concept of active and non-active physical
memory: we call it online and offline. Some tweaks to the information
that we export might be all that you need, instead of creating a new
interface.

Looks like. And the tweaks could be handled by the user space kexec-tools.

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?


A good example of all of the hotplug stuff enabled for a normal machine
is this .config, it boots on my 4-way PIII Xeon.

http://www.sr71.net/patches/2.6.12/2.6.12-rc1-mhp1/configs/config-i386-sparse-hotplug

You're welcome to borrow the machine that I normally boot this config
on. Should make booting it relatively foolproof. :)

-- Dave


------------------------------------------------------------------------

block_size_bytes: The size of each memory section (in hex)

This value is per memoryXXXX directory, right?


Regards, Hari
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/