On Sat, Nov 05, 2011 at 10:00:52AM +0800, Nai Xia wrote: > > <SNIP> > > The only safe way to do it is to have _two_ different vmas, with two > > different ->vm_pgoff. Then it will work. And by always creating a new > > vma we'll always have it queued at the end, and it'll be safe for the > > same reasons fork is safe. > > > > Always allocate a new vma, and then after the whole vma copy is > > complete, look if we can merge and free some vma. After the fact, so > > it means we can't use vma_merge anymore. vma_merge assumes the > > new_range is "virtual" and no vma is mapped there I think. Anyway > > that's an implementation issue. In some unlikely case we'll allocate 1 > > more vma than before, and we'll free it once mremap is finished, but > > that's small problem compared to solving this once and for all. > > > > And that will fix it without ordering games and it'll fix the *vmap= > > new_vma case too. That case really tripped on me as I was assuming > > *that* was correct. > > Yes. "Allocating a new vma, copy first and merge later " seems > another solution without the tricky reordering. But you know, > I now share some of Hugh's feeling that maybe we are too > desperate using racing in places where locks are simpler > and guaranteed to be safe. > I'm tending to agree. The number of cases that must be kept in mind is getting too tricky. Taking the anon_vma lock may be slower but at the risk of sounding chicken, it's easier to understand. > But I think Mel indicated that anon_vma_locking might be > harmful to JVM SMP performance. > How severe you expect this to be, Mel ? > I would only expect it to be a problem during garbage collection when there is a greater likelihood that mremap is heavily used. While it would have been nice to avoid additional overhead in mremap, I don't think the JVM GC case on its own is sufficient justification to avoid taking the anon_vma lock. -- Mel Gorman 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>