From mboxrd@z Thu Jan 1 00:00:00 1970 From: Catalin Marinas Subject: Re: TLB and PTE coherency during munmap Date: Mon, 3 Jun 2013 11:01:39 +0100 Message-ID: References: <51A45861.1010008@gmail.com> <20130529122728.GA27176@twins.programming.kicks-ass.net> <51A5F7A7.5020604@synopsys.com> <20130529175125.GJ12193@twins.programming.kicks-ass.net> <20130603090501.GI5910@twins.programming.kicks-ass.net> <20130603091621.GA23320@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: Received: from mail-pd0-f172.google.com ([209.85.192.172]:37216 "EHLO mail-pd0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754331Ab3FCKCA (ORCPT ); Mon, 3 Jun 2013 06:02:00 -0400 Received: by mail-pd0-f172.google.com with SMTP id t10so1909566pdi.31 for ; Mon, 03 Jun 2013 03:01:59 -0700 (PDT) In-Reply-To: <20130603091621.GA23320@gmail.com> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Ingo Molnar Cc: Peter Zijlstra , Max Filippov , Vineet Gupta , KAMEZAWA Hiroyuki , "linux-arch@vger.kernel.org" , linux-mm , Ralf Baechle , Chris Zankel , Marc Gauthier , linux-xtensa@linux-xtensa.org, Hugh Dickins , Thomas Gleixner , Linus Torvalds , Andrew Morton On 3 June 2013 10:16, Ingo Molnar wrote: > > * Peter Zijlstra wrote: > >> On Fri, May 31, 2013 at 08:09:17AM +0400, Max Filippov wrote: >> > Hi Peter, >> > >> > On Wed, May 29, 2013 at 9:51 PM, Peter Zijlstra wrote: >> > > What about something like this? >> > >> > With that patch I still get mtest05 firing my TLB/PTE incoherency >> > check in the UP PREEMPT_VOLUNTARY configuration. This happens after >> > zap_pte_range completion in the end of unmap_region because of >> > rescheduling called in the following call chain: >> >> OK, so there two options; completely kill off fast-mode or something >> like the below where we add magic to the scheduler :/ >> >> I'm aware people might object to something like the below -- but since >> its a possibility I thought we ought to at least mention it. >> >> For those new to the thread; the problem is that since the introduction >> of preemptible mmu_gather the traditional UP fast-mode is broken. >> Fast-mode is where we free the pages first and flush TLBs later. This is >> not a problem if there's no concurrency, but obviously if you can >> preempt there now is. >> >> I think I prefer completely killing off fast-mode esp. since UP seems to >> go the way of the Dodo and it does away with an exception in the >> mmu_gather code. >> >> Anyway; opinions? Linus, Thomas, Ingo? > > Since UP kernels have not been packaged up by major distros for years, and > since the live-patching of SMP kernels (the SMP alternative-instructions > patching machinery) does away with a big chunk of the SMP cost, I guess UP > kernels are slowly becoming like TINY_RCU: interesting but not really a > primary design goal? > > ( Another reason for reducing SMP vs. UP complexity in this area would be > the fact that we had a few bad regressions lately - the TLB code is not > getting simpler, and bugs are getting discovered and fixed slower. ) > > At least that's the x86 perspective. ARM might still see it differently? On ARM there is a lot of ongoing work on single zImage for multiple SoCs and this implies SMP kernels. There is an SMP_ON_UP feature which does run-time code patching to optimise the UP case in a few places. Regarding tlb_fast_mode(), the ARM-specific implementation is always 0 on ARMv7 even if UP because of speculative TLB loads (the MMU could pretty much act as a separate processor). Catalin From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx156.postini.com [74.125.245.156]) by kanga.kvack.org (Postfix) with SMTP id C05B76B006C for ; Mon, 3 Jun 2013 06:02:00 -0400 (EDT) Received: by mail-pd0-f173.google.com with SMTP id v10so422433pde.4 for ; Mon, 03 Jun 2013 03:01:59 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20130603091621.GA23320@gmail.com> References: <51A45861.1010008@gmail.com> <20130529122728.GA27176@twins.programming.kicks-ass.net> <51A5F7A7.5020604@synopsys.com> <20130529175125.GJ12193@twins.programming.kicks-ass.net> <20130603090501.GI5910@twins.programming.kicks-ass.net> <20130603091621.GA23320@gmail.com> From: Catalin Marinas Date: Mon, 3 Jun 2013 11:01:39 +0100 Message-ID: Subject: Re: TLB and PTE coherency during munmap Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: Ingo Molnar Cc: Peter Zijlstra , Max Filippov , Vineet Gupta , KAMEZAWA Hiroyuki , "linux-arch@vger.kernel.org" , linux-mm , Ralf Baechle , Chris Zankel , Marc Gauthier , linux-xtensa@linux-xtensa.org, Hugh Dickins , Thomas Gleixner , Linus Torvalds , Andrew Morton On 3 June 2013 10:16, Ingo Molnar wrote: > > * Peter Zijlstra wrote: > >> On Fri, May 31, 2013 at 08:09:17AM +0400, Max Filippov wrote: >> > Hi Peter, >> > >> > On Wed, May 29, 2013 at 9:51 PM, Peter Zijlstra wrote: >> > > What about something like this? >> > >> > With that patch I still get mtest05 firing my TLB/PTE incoherency >> > check in the UP PREEMPT_VOLUNTARY configuration. This happens after >> > zap_pte_range completion in the end of unmap_region because of >> > rescheduling called in the following call chain: >> >> OK, so there two options; completely kill off fast-mode or something >> like the below where we add magic to the scheduler :/ >> >> I'm aware people might object to something like the below -- but since >> its a possibility I thought we ought to at least mention it. >> >> For those new to the thread; the problem is that since the introduction >> of preemptible mmu_gather the traditional UP fast-mode is broken. >> Fast-mode is where we free the pages first and flush TLBs later. This is >> not a problem if there's no concurrency, but obviously if you can >> preempt there now is. >> >> I think I prefer completely killing off fast-mode esp. since UP seems to >> go the way of the Dodo and it does away with an exception in the >> mmu_gather code. >> >> Anyway; opinions? Linus, Thomas, Ingo? > > Since UP kernels have not been packaged up by major distros for years, and > since the live-patching of SMP kernels (the SMP alternative-instructions > patching machinery) does away with a big chunk of the SMP cost, I guess UP > kernels are slowly becoming like TINY_RCU: interesting but not really a > primary design goal? > > ( Another reason for reducing SMP vs. UP complexity in this area would be > the fact that we had a few bad regressions lately - the TLB code is not > getting simpler, and bugs are getting discovered and fixed slower. ) > > At least that's the x86 perspective. ARM might still see it differently? On ARM there is a lot of ongoing work on single zImage for multiple SoCs and this implies SMP kernels. There is an SMP_ON_UP feature which does run-time code patching to optimise the UP case in a few places. Regarding tlb_fast_mode(), the ARM-specific implementation is always 0 on ARMv7 even if UP because of speculative TLB loads (the MMU could pretty much act as a separate processor). Catalin -- 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