Messages in this thread | | | Date | Thu, 4 Oct 2012 12:45:51 -0400 | From | Konrad Rzeszutek Wilk <> | Subject | Re: [PATCH 04/13] x86, mm: Revert back good_end setting for 64bit |
| |
On Thu, Oct 04, 2012 at 08:57:55AM -0700, Yinghai Lu wrote: > On Mon, Oct 1, 2012 at 4:00 AM, Stefano Stabellini > <stefano.stabellini@eu.citrix.com> wrote: > > On Sun, 30 Sep 2012, Yinghai Lu wrote: > >> After > >> > >> | commit 8548c84da2f47e71bbbe300f55edb768492575f7 > >> | Author: Takashi Iwai <tiwai@suse.de> > >> | Date: Sun Oct 23 23:19:12 2011 +0200 > >> | > >> | x86: Fix S4 regression > >> | > >> | Commit 4b239f458 ("x86-64, mm: Put early page table high") causes a S4 > >> | regression since 2.6.39, namely the machine reboots occasionally at S4 > >> | resume. It doesn't happen always, overall rate is about 1/20. But, > >> | like other bugs, once when this happens, it continues to happen. > >> | > >> | This patch fixes the problem by essentially reverting the memory > >> | assignment in the older way. > >> > >> Have some page table around 512M again, that will prevent kdump to find 512M > >> under 768M. > >> > >> We need revert that reverting, so we could put page table high again for 64bit. > >> > >> Takashi agreed that S4 regression could be something else. > >> > >> https://lkml.org/lkml/2012/6/15/182 > >> > >> Signed-off-by: Yinghai Lu <yinghai@kernel.org> > >> --- > >> arch/x86/mm/init.c | 2 +- > >> 1 files changed, 1 insertions(+), 1 deletions(-) > >> > >> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c > >> index 9f69180..aadb154 100644 > >> --- a/arch/x86/mm/init.c > >> +++ b/arch/x86/mm/init.c > >> @@ -76,8 +76,8 @@ static void __init find_early_table_space(struct map_range *mr, > >> #ifdef CONFIG_X86_32 > >> /* for fixmap */ > >> tables += roundup(__end_of_fixed_addresses * sizeof(pte_t), PAGE_SIZE); > >> -#endif > >> good_end = max_pfn_mapped << PAGE_SHIFT; > >> +#endif > >> > >> base = memblock_find_in_range(start, good_end, tables, PAGE_SIZE); > >> if (!base) > > > > Isn't this going to cause init_memory_mapping to allocate pagetable > > pages from memory not yet mapped? > > but 64bit is using ioremap to access those page table buf. > > > Last time I spoke with HPA and Thomas about this, they seem to agree > > that it isn't a very good idea. > > Also, it is proven to cause a certain amount of headaches on Xen, > > see commit d8aa5ec3382e6a545b8f25178d1e0992d4927f19. > > this patchset will allocate page table buf one time only.
As in, if your machine has 8GB, it will allocate pagetables that span 0->8GB at once?
> So could use ram under 1M to map that page table at first.
Could or does this patch do it? And why 1MB? > > so that will make it xen happy ?
The issues that Xen faces are purely due to the fact that they must be RO when they are in use. I believe (and without actually checking it just to make sure) that it does not matter where the page-tables are located. But with the current generic code the location is quite linear: it starts with pgt_buf_start and goes up to pgt_buf_top. So how would this patch move the location of the page-table to be under 1MB?
Perhaps we are talking about seperate topics?
My recollection of memblock_find_in_range is that it will try the end of the range to find a suitable "chunk" that satisfies the 'size' and 'aligment' parameters?
| |