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.
So with the above hunk you can add my tested-by.
cheers
--
To unsubscribe from this list: send the line "unsubscribe trinity" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
