On Thu, 29 May 2014, Michael Ellerman wrote: > > Unfortunately I don't know our mm/hugetlb code well enough to give you a good > answer. Ben had a quick look at our follow_huge_addr() and thought it looked > "fishy". He suggested something like what we do in gup_pte_range() with > page_cache_get_speculative() might be in order. Fishy indeed, ancient code that was only ever intended for stats-like usage, not designed for actually getting a hold on the page. But I don't think there's a big problem to getting the locking right: just hope it doesn't require a different strategy on each architecture - often an irritation with hugetlb. Naoya-san will sort it out in due course (not 3.15) I expect, but will probably need testing help. > > 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> > > I've hit it twice in two runs: > > If I tell trinity to skip sys_move_pages() it runs for hours. That's sad. Sorry for wasting your time with my patch, thank you for trying it. What you see might be a consequence of the locking deficiency I mentioned, given trinity's deviousness; though if it's being clever like that, I would expect it to have already found the equivalent issue on x86-64. So probably not, probably another issue. As I've said elsewhere, I think we need to go with disablement for now. Hugh -- 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
