Messages in this thread | | | Date | Wed, 13 Oct 2010 11:12:24 -0700 | From | Yinghai Lu <> | Subject | Re: [PATCH 0/4] memblock related fixes for -tip |
| |
On 10/13/2010 09:31 AM, Jeremy Fitzhardinge wrote: > On 10/12/2010 10:40 PM, Yinghai Lu wrote: >> On 10/12/2010 04:37 PM, Jeremy Fitzhardinge wrote: >>> On 10/12/2010 02:12 PM, Yinghai Lu wrote: >>>> On 10/12/2010 11:41 AM, Jeremy Fitzhardinge wrote: >>>>> On 10/04/2010 02:57 PM, Yinghai Lu wrote: >>>>>> Please check memblock related patches >>>>>> >>>>>> [PATCH 1/4] memblock: Fix big size with find_region() >>>>>> [PATCH -v5 2/4] x86, memblock: Fix crashkernel allocation >>>>>> [PATCH 3/4] x86, memblock: Remove __memblock_x86_find_in_range_size() >>>>>> [PATCH 4/4] x86, mm, memblock, 32bit: Make add_highpages honor early reserved ranges >>>>>> >>>>>> first one should get into core/memblock branch, and others should be in x86/mm/memeblock branch >>>>> BTW, the memblock changes prevent the kernel from booting under Xen; it >>>>> crashes while setting up the linear maps. I haven't worked out what's >>>>> failing yet, aside from bisecting it down to one of a9ce6bc151000 or >>>>> 72d7c3b33c9808 (they don't compile in isolation so I had to skip them, >>>>> but both are likely looking, but unfortunately large, complex and hard >>>>> to further subdivide). >>>>> >>>>> I'll look further into this, but just a heads-up for the upcoming merge >>>>> window. >>>>> >>>> please use >>>> >>>> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-2.6-yinghai.git memblock >>>> >>>> to find which commit cause xen broken. >>>> >>>> two xen related patch are folded into first converting commit. >>> Note that ce883cfc65c51e24 doesn't compile: >>> >>> /home/jeremy/git/upstream/arch/x86/kernel/e820.c: In function >>> ‘find_e820_area_size’: >>> /home/jeremy/git/upstream/arch/x86/kernel/e820.c:764: error: expected >>> ‘;’ before ‘return’ >>> >>> However, I can fix it with the obvious fix, and the Xen boot failure >>> bisects to this change. >>> >>> The specific crash is when constructing the initial pagetable, when Xen >>> tries to remap a newly allocated pagetable page read-only, and finds the >>> allocated page isn't mapped within the linear map. Since it is in the >>> middle of creating the linear map, I guess its quite possible that the >>> allocation order has changed, and it starts allocating pages which are >>> not yet mapped, whereas before it was allocating already-mapped ones. >> you can limit the allocation of pagetable page further ... >> >> xen doesn't honor max_pfn_mapped? > > What do you mean? Xen sets max_pfn_mapped when it does the early > mapping of the kernel space, but I don't see how it relates to this > stage of mapping?
We are using max_pfn_mapped to upper limit to find range that can be used as early stage.
so maybe you have max_pfn_mapped set too early and too big?
> >>> I'll see if I can confirm this hypothesis and see if I can work around >>> it (is poses some problems, because it means that when the pages later >>> become mapped, I need to make sure they get mapped RO). >> please check following debug patch, it will try find area bottom up... >> >> Subject: [PATCH] x86, memblock: Add x86 version of memblock_find_in_range() >> >> Generic version is going from high to low, and it seems it can not find >> right area compact enough. >> >> the x86 version will go from goal to limit and just like the way We used >> for early_res >> >> use ARCH_FIND_MEMBLOCK_AREA to select from them. > > Thanks, that fixes the problem. I would ideally like to make the the > Xen code independent of the page allocation ordering, but it looks like > it will be very tricky since we effectively make use of the pagetable as > a way of storing one bit of information about each page before there's a > struct page in place. > > So this patch looks good to me (but there's no need to make it a > separate config option).
that is for debug purpose only. We really want to do top-down than bottom-up.
Thanks
Yinghai -- 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/
| |