Here are the TLB patches as requested: ---8<--- The function ptep_set_access_flags() is only ever invoked to upgrade access permissions on a PTE. That makes it safe to skip flushing the TLBs on remote TLBs. The worst that can happen is a spurious page fault on other CPUs, which would flush that TLB entry.
Lazily letting another CPU incur a spurious page fault occasionally is (much!) cheaper than aggressively flushing everybody else's TLB. Signed-off-by: Rik van Riel <r...@redhat.com> Cc: Linus Torvalds <torva...@linux-foundation.org> Cc: Andrew Morton <a...@linux-foundation.org> Cc: Peter Zijlstra <a.p.zijls...@chello.nl> Cc: Michel Lespinasse <wal...@google.com> Cc: Ingo Molnar <mi...@kernel.org> --- arch/x86/mm/pgtable.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c index 8573b83..b3b852c 100644 --- a/arch/x86/mm/pgtable.c +++ b/arch/x86/mm/pgtable.c @@ -310,7 +310,7 @@ int ptep_set_access_flags(struct vm_area_struct *vma, if (changed && dirty) { *ptep = entry; pte_update_defer(vma->vm_mm, address, ptep); - flush_tlb_page(vma, address); + __flush_tlb_one(address); } return changed; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/