On Thu, Jul 23, 2015 at 09:55:33AM -0700, Dave Hansen wrote: > On 07/23/2015 09:16 AM, Catalin Marinas wrote: > > Anyway, if you want to keep the option of a full TLB flush for x86 on > > huge pages, I'm happy to repost a v2 with a separate > > flush_tlb_pmd_huge_page that arch code can define as it sees fit. > > I think your patch is fine on x86. We need to keep an eye out for any > regressions, but I think it's OK. That's my view as well. I've read more of the other thread and I quote Ingo: " It barely makes sense for a 2 pages and gets exponentially worse. It's probably done in microcode and its performance is horrible. " So in our case it's just 1 page (not 2, not 33), and considering it prevents to invalidate all other TLB entries, it's most certainly a win: it requires zero additional infrastructure and best of all it can also avoid to flush the entire TLB for remote CPUs too again without infrastructure or pfn arrays or multiple invlpg. As further confirmation that for 1 entry invlpg is worth it, even flush_tlb_page->flush_tlb_func invokes __flush_tlb_single in the IPI handler instead of local_flush_tlb(). So the discussion there was about the additional infrastructure and a flood of invlpg, perhaps more than 33, I agree a local_flush_tlb() sounds better for that. The question left for x86 is if invlpg is even slower for 2MB pages than it is for 4k pages, but I'd be surprised if it is, especially on newer CPUs where the TLB can use different page size for each TLB entry. Why we didn't do flush_tlb_page before wasn't related to such a concern at least. -- 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>