On Sat, Aug 06, 2011 at 06:58:04PM +0200, aarcange@xxxxxxxxxx wrote: > From: Andrea Arcangeli <aarcange@xxxxxxxxxx> > > This replaces ptep_clear_flush() with ptep_get_and_clear() and a single > flush_tlb_range() at the end of the loop, to avoid sending one IPI for each > page. > > The mmu_notifier_invalidate_range_start/end section is enlarged accordingly but > this is not going to fundamentally change things. It was more by accident that > the region under mremap was for the most part still available for secondary > MMUs: the primary MMU was never allowed to reliably access that region for the > duration of the mremap (modulo trapping SIGSEGV on the old address range which > sounds unpractical and flakey). If users wants secondary MMUs not to lose > access to a large region under mremap they should reduce the mremap size > accordingly in userland and run multiple calls. Overall this will run faster so > it's actually going to reduce the time the region is under mremap for the > primary MMU which should provide a net benefit to apps. > > For KVM this is a noop because the guest physical memory is never mremapped, > there's just no point it ever moving it while guest runs. One target of this > optimization is JVM GC (so unrelated to the mmu notifier logic). > > Signed-off-by: Andrea Arcangeli <aarcange@xxxxxxxxxx> Acked-by: Mel Gorman <mgorman@xxxxxxx> -- 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>