From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752734Ab2JZEXs (ORCPT ); Fri, 26 Oct 2012 00:23:48 -0400 Received: from mail-we0-f174.google.com ([74.125.82.174]:45350 "EHLO mail-we0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751823Ab2JZEXr (ORCPT ); Fri, 26 Oct 2012 00:23:47 -0400 MIME-Version: 1.0 In-Reply-To: <508A0A0D.4090001@redhat.com> References: <20121025121617.617683848@chello.nl> <20121025124832.840241082@chello.nl> <5089F5B5.1050206@redhat.com> <508A0A0D.4090001@redhat.com> From: Linus Torvalds Date: Thu, 25 Oct 2012 21:23:25 -0700 X-Google-Sender-Auth: HMW8VLn3pCD9wZnaq_5arXhBo5Q Message-ID: Subject: Re: [PATCH 05/31] x86/mm: Reduce tlb flushes from ptep_set_access_flags() To: Rik van Riel Cc: 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 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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. So it's quite possible we could do this to the pgtable-generic.c code too. However, we don't actually have any generic way to do a local single-address flush (the __flush_tlb_one() thing is architecture-specific, although it exists on a few architectures). We'd need to add a local_flush_tlb_page(vma, address) function. Alternatively, we could decide to use the "tlb_fix_spurious_fault()" thing in there. Possibly just do it unconditionally in the caller - or even just specify that the fault handler has to do it. And stop returning a value at all from ptep_set_access_flags() (I *think* that's the only thing the return value gets used for - flushing the TLB on the local cpu for the cpu's that want it). > Want to just remove the TLB flush entirely and see > if anything breaks in 3.8-rc1? > > From reading the code again, it looks like things > should indeed work ok. I would be open to it, but just in case it causes bisectable problems I'd really want to see it in two patches ("make it always do the local flush" followed by "remove even the local flush"), and then it would pinpoint any need. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx185.postini.com [74.125.245.185]) by kanga.kvack.org (Postfix) with SMTP id 51A346B0074 for ; Fri, 26 Oct 2012 00:23:47 -0400 (EDT) Received: by mail-wg0-f45.google.com with SMTP id dq12so1568679wgb.26 for ; Thu, 25 Oct 2012 21:23:45 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <508A0A0D.4090001@redhat.com> References: <20121025121617.617683848@chello.nl> <20121025124832.840241082@chello.nl> <5089F5B5.1050206@redhat.com> <508A0A0D.4090001@redhat.com> From: Linus Torvalds Date: Thu, 25 Oct 2012 21:23:25 -0700 Message-ID: Subject: Re: [PATCH 05/31] x86/mm: Reduce tlb flushes from ptep_set_access_flags() Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: Rik van Riel Cc: Peter Zijlstra , Andrea Arcangeli , Mel Gorman , Johannes Weiner , Thomas Gleixner , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Ingo Molnar 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. 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. So it's quite possible we could do this to the pgtable-generic.c code too. However, we don't actually have any generic way to do a local single-address flush (the __flush_tlb_one() thing is architecture-specific, although it exists on a few architectures). We'd need to add a local_flush_tlb_page(vma, address) function. Alternatively, we could decide to use the "tlb_fix_spurious_fault()" thing in there. Possibly just do it unconditionally in the caller - or even just specify that the fault handler has to do it. And stop returning a value at all from ptep_set_access_flags() (I *think* that's the only thing the return value gets used for - flushing the TLB on the local cpu for the cpu's that want it). > Want to just remove the TLB flush entirely and see > if anything breaks in 3.8-rc1? > > From reading the code again, it looks like things > should indeed work ok. I would be open to it, but just in case it causes bisectable problems I'd really want to see it in two patches ("make it always do the local flush" followed by "remove even the local flush"), and then it would pinpoint any need. Linus -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org