From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx175.postini.com [74.125.245.175]) by kanga.kvack.org (Postfix) with SMTP id B076B6B005A for ; Thu, 28 Jun 2012 10:57:19 -0400 (EDT) Date: Thu, 28 Jun 2012 15:53:28 +0100 From: Catalin Marinas Subject: Re: [PATCH 08/20] mm: Optimize fullmm TLB flushing Message-ID: <20120628145327.GA17242@arm.com> References: <20120627211540.459910855@chello.nl> <20120627212831.137126018@chello.nl> <1340838154.10063.86.camel@twins> <1340838807.10063.90.camel@twins> <20120628091627.GB8573@arm.com> <1340879984.20977.80.camel@pasglop> <1340881196.28750.16.camel@twins> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1340881196.28750.16.camel@twins> Sender: owner-linux-mm@kvack.org List-ID: To: Peter Zijlstra Cc: Benjamin Herrenschmidt , Linus Torvalds , "linux-kernel@vger.kernel.org" , "linux-arch@vger.kernel.org" , "linux-mm@kvack.org" , Thomas Gleixner , Ingo Molnar , "akpm@linux-foundation.org" , Rik van Riel , Hugh Dickins , Mel Gorman , Nick Piggin , Alex Shi , "Nikunj A. Dadhania" , Konrad Rzeszutek Wilk , David Miller , Russell King , Chris Metcalf , Martin Schwidefsky , Tony Luck , Paul Mundt , Jeff Dike , Richard Weinberger , Ralf Baechle , Kyle McMartin , James Bottomley , Chris Zankel On Thu, Jun 28, 2012 at 11:59:56AM +0100, Peter Zijlstra wrote: > On Thu, 2012-06-28 at 20:39 +1000, Benjamin Herrenschmidt wrote: > > On Thu, 2012-06-28 at 10:16 +0100, Catalin Marinas wrote: > > > That's definitely an issue on ARM and it was hit on older kernels. > > > Basically ARM processors can cache any page translation level in the > > > TLB. We need to make sure that no page entry at any level (either cached > > > in the TLB or not) points to an invalid next level table (hence the TLB > > > shootdown). For example, in cases like free_pgd_range(), if the cached > > > pgd entry points to an already freed pud/pmd table (pgd_clear is not > > > enough) it may walk the page tables speculatively cache another entry in > > > the TLB. Depending on the random data it reads from an old table page, > > > it may find a global entry (it's just a bit in the pte) which is not > > > tagged with an ASID (application specific id). A latter flush_tlb_mm() > > > only flushes the current ASID and doesn't touch global entries (used > > > only by kernel mappings). So we end up with global TLB entry in user > > > space that overrides any other application mapping. > > > > Right, that's the typical scenario. I haven't looked at your flush > > implementation though, but surely you can defer the actual freeing so > > you can batch them & limit the number of TLB flushes right ? > > Yes they do.. its just the up-front TLB invalidate for fullmm that's a > problem. The upfront invalidate is fine (i.e. harmless), it's the tlb_flush_mmu() change to check for !tlb->fullmm that's not helpful on ARM. -- 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