Re: [RFC] Obtaining memory information for kexec/kdump
From: Hariprasad Nellitheertha (hari_at_in.ibm.com)
Date: 03/28/05
- Previous message: Geert Uytterhoeven: "Re: [PATCH] no need to check for NULL before calling kfree() -fs/ext2/"
- In reply to: Dave Hansen: "Re: [RFC] Obtaining memory information for kexec/kdump"
- Next in thread: Dave Hansen: "Re: [RFC] Obtaining memory information for kexec/kdump"
- Reply: Dave Hansen: "Re: [RFC] Obtaining memory information for kexec/kdump"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 28 Mar 2005 18:30:22 +0530 To: Dave Hansen <haveblue@us.ibm.com>
Dave Hansen wrote:
> 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?
Because we are putting the starting address, end address and
the memory type against each entry (just like in
/proc/iomem). Of course, we can figure out the ending
address knowing the starting address and the section size.
>
>> 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
In addition to this, I also needed to pull-in the
J-zone_resize_sem.patch to get it to compile.
Would it be possible to make this a separate patch-set so
that it does not depend on memory hotplug.
>
>
>>>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.
I tested this on my PIII 256M machine.
/sys/devices/system/memory showed 4 memory sections each of
size 64MB. There are a couple of issues that we noticed. We
will not be able to spot those physical memory areas which
the OS does not use (such as the region between 640k and
1MB). Also, when I booted the system with the mem=100M
option, two entries (memory0 and memory1) turned up. With
block_size_bytes being 64M, this turns out equivalent to a
system with 128M memory.
If block_size_bytes was per-directory, it would be easier in
such situations.
Regards, Hari
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Geert Uytterhoeven: "Re: [PATCH] no need to check for NULL before calling kfree() -fs/ext2/"
- In reply to: Dave Hansen: "Re: [RFC] Obtaining memory information for kexec/kdump"
- Next in thread: Dave Hansen: "Re: [RFC] Obtaining memory information for kexec/kdump"
- Reply: Dave Hansen: "Re: [RFC] Obtaining memory information for kexec/kdump"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
