Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932632Ab2JZMeG (ORCPT ); Fri, 26 Oct 2012 08:34:06 -0400 Received: from mail-qc0-f174.google.com ([209.85.216.174]:44095 "EHLO mail-qc0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758615Ab2JZMeD (ORCPT ); Fri, 26 Oct 2012 08:34:03 -0400 MIME-Version: 1.0 In-Reply-To: References: <20121025121617.617683848@chello.nl> <20121025124832.840241082@chello.nl> <5089F5B5.1050206@redhat.com> <508A0A0D.4090001@redhat.com> Date: Fri, 26 Oct 2012 05:34:02 -0700 Message-ID: Subject: Re: [PATCH 05/31] x86/mm: Reduce tlb flushes from ptep_set_access_flags() From: Michel Lespinasse To: Linus Torvalds Cc: Rik van Riel , Peter Zijlstra , Andrea Arcangeli , Mel Gorman , Johannes Weiner , Thomas Gleixner , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Ingo Molnar Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1857 Lines: 43 On Thu, Oct 25, 2012 at 9:23 PM, Linus Torvalds wrote: > On Thu, Oct 25, 2012 at 8:57 PM, Rik van Riel wrote: >> >> That may not even be needed. Apparently Intel chips >> automatically flush an entry from the TLB when it >> causes a page fault. I assume AMD chips do the same, >> because flush_tlb_fix_spurious_fault evaluates to >> nothing on x86. > > Yes. It's not architected as far as I know, though. But I agree, it's > possible - even likely - we could avoid TLB flushing entirely on x86. Actually, it is architected on x86. This was first described in the intel appnote 317080 "TLBs, Paging-Structure Caches, and Their Invalidation", last paragraph of section 5.1. Nowadays, the same contents are buried somewhere in Volume 3 of the architecture manual (in my copy: 4.10.4.1 Operations that Invalidate TLBs and Paging-Structure Caches) > If you want to try it, I would seriously suggest you do it as a > separate commit though, just in case. > >> Are there architectures where we do need to flush >> remote TLBs on upgrading the permissions on a PTE? > > I *suspect* that whole TLB flush just magically became an SMP one > without anybody ever really thinking about it. I would be very worried about assuming every non-x86 arch has similar TLB semantics. However, if their fault handlers always invalidate TLB for pages that get spurious faults, then skipping the remote invalidation would be fine. (I believe this is what tlb_fix_spurious_fault() is for ?) -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/