On Tue 26-07-16 22:04:16, zhong jiang wrote: > On 2016/7/26 15:58, Michal Hocko wrote: > > On Fri 22-07-16 07:17:37, Naoya Horiguchi wrote: > > [...] > >> I think that (src_pte != dst_pte) can happen and that's ok if there's no > >> migration entry. > > We have discussed that with Naoya off-list and couldn't find a scenario > > when parent would have !shared pmd while child would have it. The only > > plausible scenario was that parent created and poppulated mapping smaller > > than 1G and then enlarged it later on so the child would see sharedable > > pud. This doesn't seem to be possible because vma_merge would bail out > > due to VM_SPECIAL check. > I do not understand that the process must have vm_special flags. if > vm_special enable, the process must not be expanded. and what does it > matter about vma_merge ?? See if (vm_flags & VM_SPECIAL) return NULL; in vma_merge. > >> But even if we have both of normal entry and migration entry > >> for one hugepage, that still looks fine to me because the running migration > >> operation fails (because there remains mapcounts on the source hugepage), > >> and all migration entries are turned back to normal entries pointing to the > >> source hugepage. > > In one case, try_to_unmap_one is first exec and successfully, mapcount > turn into zero. then we get the pte lock, if src_pte!-dst_pte, it > maybe lead to the dst_pte is from migrate pte to normal pte, while the > normal pte turn into migaret pte,, is right ? I am sorry but I have hard time following your arguments here. Could you be more specific please? > > Agreed. > > > >> Could you try to see and share what happens on your workload with > >> Michal's patch? > > > > Zhong Jiang did you have chance to retest with the BUG_ON changed? Anything for this? -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>