Re: [PATCH] hugetlb: restrict hugepage_migration_support() to x86_64 (Re: BUG at mm/memory.c:1489!)

On Fri, May 30, 2014 at 11:35:16AM +1000, Michael Ellerman wrote:
> On Thu, 2014-05-29 at 14:34 -0400, Naoya Horiguchi wrote:
> > On Thu, May 29, 2014 at 06:59:43PM +1000, Michael Ellerman wrote:
> > > Applying your patch and running trinity pretty immediately results in the
> > > following, which looks related (sys_move_pages() again) ?
> > >
> > > Unable to handle kernel paging request for data at address 0xf2000f80000000
> > > Faulting instruction address: 0xc0000000001e29bc
> > > cpu 0x1b: Vector: 300 (Data Access) at [c0000003c70f76f0]
> > >     pc: c0000000001e29bc: .remove_migration_pte+0x9c/0x320
> > >     lr: c0000000001e29b8: .remove_migration_pte+0x98/0x320
> > >     sp: c0000003c70f7970
> > >    msr: 8000000000009032
> > >    dar: f2000f80000000
> > >  dsisr: 40000000
> > >   current = 0xc0000003f9045800
> > >   paca    = 0xc000000001dc6c00   softe: 0        irq_happened: 0x01
> > >     pid   = 3585, comm = trinity-c27
> > > enter ? for help
> > > [c0000003c70f7a20] c0000000001bce88 .rmap_walk+0x328/0x470
> > > [c0000003c70f7ae0] c0000000001e2904 .remove_migration_ptes+0x44/0x60
> > > [c0000003c70f7b80] c0000000001e4ce8 .migrate_pages+0x6d8/0xa00
> > > [c0000003c70f7cc0] c0000000001e55ec .SyS_move_pages+0x5dc/0x7d0
> > > [c0000003c70f7e30] c00000000000a1d8 syscall_exit+0x0/0x98
> > > --- Exception: c01 (System Call) at 00003fff7b2b30a8
> > > SP (3fffe09728a0) is in userspace
> > > 1b:mon>
> >
> > Sorry for inconvenience on your testing.
>  
> That's fine, it's good to find bugs :)
> 
> > Hugepage migration is enabled for archs which have pmd-level hugepage
> > (including ppc64,) but not tested except for x86_64.
> > hugepage_migration_support() controls this so the following patch should
> > help you avoid the problem, I believe.
> > Could you try to test with it?
> 
> Sure. So this patch, in addition to Hugh's patch to remove the BUG_ON(), does
> avoid the crash above (remove_migration_pte()).
> 
> I dropped Hugh's patch, as he has decided he doesn't like it, and added the
> following hunk instead:
> 
> diff --git a/include/linux/mempolicy.h b/include/linux/mempolicy.h
> index 3c1b968..f230a97 100644
> --- a/include/linux/mempolicy.h
> +++ b/include/linux/mempolicy.h
> @@ -175,6 +175,12 @@ static inline int vma_migratable(struct vm_area_struct *vma)
>  {
>         if (vma->vm_flags & (VM_IO | VM_PFNMAP))
>                 return 0;
> +
> +#ifndef CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION
> +       if (vma->vm_flags & VM_HUGETLB)
> +               return 0;
> +#endif
> +
>         /*
>          * Migration allocates pages in the highest zone. If we cannot
>          * do so then migration (at least from node to node) is not
> 
> 
> Which seems to be what Hugh was referring to in his mail - correct me if I'm
> wrong Hugh.
> 
> With your patch and the above hunk I can run trinity happily for a while,
> whereas without it crashes almost immediately.

Great.

> So with the above hunk you can add my tested-by.

OK, thank you for your help.

I'll post the revised patch later.

Thanks,
Naoya Horiguchi

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>