On Tue, 30 Oct 2007 11:19:11 -0800 Badari Pulavarty <[EMAIL PROTECTED]> wrote:
> Hi KAME, > > As I mentioned while ago, ppc64 does not export information about > "system RAM" in /proc/iomem. Looking at the code and usage > scenerios I am not sure what its really serving. Could you > explain what its purpose & how the range can be invalid ? > Hm, I added walk_memory_resource() for hot-add, at first. Size of memory section is fixed and just depend on architecture, but any machine can have any memory-hole within continuous memory-section-size range of physical memory. Then we have to detect which page can be target of online_page() and which are leaved as Reserved. ioresource was good structure for remembering "which memory is conventional memory" and i386/x86_64/ia64 registered conventional memory as "System RAM", when I posted patch. (just say "System Ram" is not for memory hotplug.) I used walk_memory_resource() again in memory hotremove. (If I rememember correctly, walk_memory_resouce() helps x86_64 memory hot-add. than our ia64 box. In our ia64 box, we do node-hotadd. Section size is 1GiB and it has some "for firmware" area in newly-added node.) > At least on ppc64, all the memory ranges we get passed comes from > /sysfs memblock information and they are guaranteed to match > device-tree entries. On ppc64, each 16MB chunk has a /sysfs entry > and it will be part of the /proc/device-tree entry. Since we do > "online" or "offline" to /sysfs entries to add/remove pages - > these ranges are guaranteed to be valid. > ok. > Since this check is redundant for ppc64, I propose following patch. > Is this acceptable ? If some one really really wants, I can code > up this to walk lmb or /proc/device-tree and verify the range & > adjust the entries for overlap (I don't see how that can happen). > ok. If ppc64 guarantees "there is no memory hole in section", please try. I have no objection. I just would like to ask to add some text to explain "ppc64 doesn't need to care memory hole in a section." Thanks, -Kame _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
