> -----Original Message-----
> From: linux-ia64-owner@xxxxxxxxxxxxxxx
> [mailto:linux-ia64-owner@xxxxxxxxxxxxxxx] On Behalf Of Mel Gorman
> Sent: 2006年11月10日 19:47
> To: Zou, Nanhai
> Cc: Horms; Andy Whitcroft; Linux-IA64; Bob Picco; Andrew Morton; Dave Hansen;
> Andi Kleen; Benjamin Herrenschmidt; Paul Mackerras; Keith Mannthey; Luck, Tony;
> KAMEZAWA Hiroyuki; Yasunori Goto; Khalid Aziz
> Subject: RE: 05e0caad3b7bd0d0fbeff980bca22f186241a501 breaks ia64 kdump
>
> On Fri, 10 Nov 2006, Zou, Nanhai wrote:
>
> >> -----Original Message-----
> >> From: linux-ia64-owner@xxxxxxxxxxxxxxx
> >> [mailto:linux-ia64-owner@xxxxxxxxxxxxxxx] On Behalf Of Zou Nan hai
> >> Sent: 2006年11月3日 18:07
> >> To: Mel Gorman
> >> Cc: Horms; Andy Whitcroft; Linux-IA64; Bob Picco; Andrew Morton; Dave
> Hansen;
> >> Andi Kleen; Benjamin Herrenschmidt; Paul Mackerras; Keith Mannthey; Luck,
> Tony;
> >> KAMEZAWA Hiroyuki; Yasunori Goto; Khalid Aziz
> >> Subject: RE: 05e0caad3b7bd0d0fbeff980bca22f186241a501 breaks ia64 kdump
> >>
> >> On Fri, 2006-11-03 at 17:27, Mel Gorman wrote:
> >>> On Fri, 3 Nov 2006, Zou, Nanhai wrote:
> >>>
> >>>> Hi,
> >>>> This patch should fix the issue.
> >>>>
> >>>
> >>> It would appear to fix the issue for IA64 but you are blotting over the
> >>> issue that the map is reporting a one page hole. On arches with really
> >>> adjacent regions that are getting merged, the regions will appear to
> >>> overlap by one page. What can happen is something like this
> >>>
> >>> PFN ranges for nodes
> >>> Node 1: 0 -> 1000
> >>> Node 0: 1000 -> 2000
> >>>
> >> Hi,
> >> But the patch Andy and you are commenting is not my patch...., It was
> >> in the previous thread.
> >> My patch was in the attachment.....
> >>
> >> Sorry for using outlook to send that patch as attachment, my Linux box
> >> was not accessable at the time when I was posting the patch.
> >> I post the patch again, and copy the discription from my previous mail.
> >>
> >> When ia64 kernel is configured as discontinuous memory model,
> >> active_pages are added through efi_memmap_walk(filter_rsvd_memory,
> >> count_node_pages).
> >> filter_rsvd_memory will filter out all regions in rsvd_regions include
> >> - boot param
> >> - mem map
> >> - initrd
> >> - command line
> >> - **** kernel code and data ***
> >> - kernel map built from efi memmap
> >> - crash kernel reserved region
> >> So the kernel code and data is excluded even without kdump support,
> >> check /proc/iomem and dmesg for early_node_data can verify that.
> >> But magically, the first kernel boots happily without any complain...,
> >> I guess that is related to the init value in memmap.
> >>
> >> This patch use another filter to add_acvitive_pages, only exclude crash
> kernel
> >> reserved region if CONFIG_KEXEC is on.
> >>
> >> Thanks
> >> Zou Nan hai
> >> --- a/arch/ia64/mm/discontig.c 2006-11-02 20:09:47.000000000 -0500
> >> +++ b/arch/ia64/mm/discontig.c 2006-11-02 19:57:27.000000000 -0500
> >> @@ -21,6 +21,7 @@
> >> #include <linux/acpi.h>
> >> #include <linux/efi.h>
> >> #include <linux/nodemask.h>
> >> +#include <linux/kexec.h>
> >> #include <asm/pgalloc.h>
> >> #include <asm/tlb.h>
> >> #include <asm/meminit.h>
> >> @@ -653,8 +654,6 @@ void call_pernode_memory(unsigned long s
> >> static __init int count_node_pages(unsigned long start, unsigned long len,
> >> int node)
> >> {
> >> unsigned long end = start + len;
> >> -
> >> - add_active_range(node, start >> PAGE_SHIFT, end >> PAGE_SHIFT);
> >> mem_data[node].num_physpages += len >> PAGE_SHIFT;
> >> if (start <= __pa(MAX_DMA_ADDRESS))
> >> mem_data[node].num_dma_physpages +=
> >> @@ -669,7 +668,31 @@ static __init int count_node_pages(unsig
> >>
> >> return 0;
> >> }
> >> +static __init int add_active_range_wrapper(unsigned long start,
> >> + unsigned long len, int node)
> >> +{
> >> + unsigned long end = start + len;
> >> + add_active_range(node, start >> PAGE_SHIFT, end >> PAGE_SHIFT);
> >> + return 0;
> >> +}
> >>
>
> The function name doesn't really tell the reader what it's meant to be
> doing. Something like register_active_ranges() might be a bit better.
>
Ok.
> >> +static int __init
> >> +filter_pernode_memory (unsigned long start, unsigned long end, void *arg)
> >> +{
> >> + void (*func)(unsigned long, unsigned long, int);
> >> + func = arg;
> >> +
> >> +#ifdef CONFIG_KEXEC
> >> + if (start > crashk_res.start && start < crashk_res.end)
> >> + start = max(start, crashk_res.end);
> >> + if (end > crashk_res.start && end < crashk_res.end)
> >> + end = min(end, crashk_res.start);
>
>
> These two checks appear to deliberatly avoid registering the kernel image
> as an active range. Was that your intention? If so, will you not hit the
> same problem with initmem?
>
No, the crashk_res.start ~ crashk_res.end is the hole reserved for 2nd kernel. The kernel himself does not to setup memmap for this area, the 2nd kernel will handle it.
As I have mentioned, this bug also exist even without kdump patch. You will see first kernels code and data is not covered by add_active_range if DISCONTIGMEM model is choosen.
Thanks
Zou Nan hai
> >> +#endif
> >> + if (start < end)
> >> + call_pernode_memory(__pa(start), end - start, func);
> >> +
> >> + return 0;
> >> +}
> >> /**
> >> * paging_init - setup page tables
> >> *
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|