From: Catalin Marinas <catalin.marinas@arm.com> To: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Russell King <rmk@arm.linux.org.uk>, Paul Mundt <lethal@linux-sh.org>, Andrea Arcangeli <aarcange@redhat.com>, Thomas Gleixner <tglx@linutronix.de>, Rik van Riel <riel@redhat.com>, Ingo Molnar <mingo@elte.hu>, "akpm@linux-foundation.org" <akpm@linux-foundation.org>, Linus Torvalds <torvalds@linux-foundation.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>, "linux-mm@kvack.org" <linux-mm@kvack.org>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, David Miller <davem@davemloft.net>, Hugh Dickins <hugh.dickins@tiscali.co.uk>, Mel Gorman <mel@csn.ul.ie>, Nick Piggin <npiggin@kernel.dk>, Chris Metcalf <cmetcalf@tilera.com>, Martin Schwidefsky <schwidefsky@de.ibm.com> Subject: Re: [RFC][PATCH 4/6] arm, mm: Convert arm to generic tlb Date: Thu, 17 May 2012 13:14:59 +0100 [thread overview] Message-ID: <20120517121459.GA18593@arm.com> (raw) In-Reply-To: <1337254086.4281.26.camel@twins> On Thu, May 17, 2012 at 12:28:06PM +0100, Peter Zijlstra wrote: > On Thu, 2012-05-17 at 10:51 +0100, Russell King wrote: > > On Thu, May 17, 2012 at 10:30:23AM +0100, Catalin Marinas wrote: > > > Another minor thing is that on newer ARM processors (Cortex-A15) we > > > need the TLB shootdown even on UP systems, so tlb_fast_mode should > > > always return 0. Something like below (untested): > > > > No Catalin, we need this for virtually all ARMv7 CPUs whether they're UP > > or SMP, not just for A15, because of the speculative prefetch which can > > re-load TLB entries from the page tables at _any_ time. > > Hmm,. so this is mostly because of the confusion/coupling between > tlb_remove_page() and tlb_remove_table() I guess. Since I don't see the > freeing of the actual pages being a problem with speculative TLB > reloads, just the page-tables. The TLB on newer ARM cores can cache intermediate entries (e.g. pmd) as long as they are valid, even if the full translation is not possible (e.g. because the pte entry is 0). With fast_mode, this could lead to the MMU reading the already freed pte page as it was pointed at by the old pmd. Older ARMv7 CPUs (Cortex-A8), don't do this intermediate caching and UP should be fine with fast_mode==1 as we already track the pte range via tlb_remove_tlb_entry(). The MMU on ARM is treated like any another agent that accesses the memory, so standard memory ordering issues apply In theory Linux can clear the pmd, free the page and it is re-used shortly after while the MMU hasn't observed the pmd_clear() yet (we don't have a barrier in this function). > Should we introduce a tlb_remove_table() regardless of > HAVE_RCU_TABLE_FREE which always queues the tables regardless of > tlb_fast_mode()? This would probably work as well (or we just add support for HAVE_RCU_TABLE_FREE on ARM). -- Catalin
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com> To: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Russell King <rmk@arm.linux.org.uk>, Paul Mundt <lethal@linux-sh.org>, Andrea Arcangeli <aarcange@redhat.com>, Thomas Gleixner <tglx@linutronix.de>, Rik van Riel <riel@redhat.com>, Ingo Molnar <mingo@elte.hu>, "akpm@linux-foundation.org" <akpm@linux-foundation.org>, Linus Torvalds <torvalds@linux-foundation.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>, "linux-mm@kvack.org" <linux-mm@kvack.org>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, David Miller <davem@davemloft.net>, Hugh Dickins <hugh.dickins@tiscali.co.uk>, Mel Gorman <mel@csn.ul.ie>, Nick Piggin <npiggin@kernel.dk>, Chris Metcalf <cmetcalf@tilera.com>, Martin Schwidefsky <schwidefsky@de.ibm.com> Subject: Re: [RFC][PATCH 4/6] arm, mm: Convert arm to generic tlb Date: Thu, 17 May 2012 13:14:59 +0100 [thread overview] Message-ID: <20120517121459.GA18593@arm.com> (raw) In-Reply-To: <1337254086.4281.26.camel@twins> On Thu, May 17, 2012 at 12:28:06PM +0100, Peter Zijlstra wrote: > On Thu, 2012-05-17 at 10:51 +0100, Russell King wrote: > > On Thu, May 17, 2012 at 10:30:23AM +0100, Catalin Marinas wrote: > > > Another minor thing is that on newer ARM processors (Cortex-A15) we > > > need the TLB shootdown even on UP systems, so tlb_fast_mode should > > > always return 0. Something like below (untested): > > > > No Catalin, we need this for virtually all ARMv7 CPUs whether they're UP > > or SMP, not just for A15, because of the speculative prefetch which can > > re-load TLB entries from the page tables at _any_ time. > > Hmm,. so this is mostly because of the confusion/coupling between > tlb_remove_page() and tlb_remove_table() I guess. Since I don't see the > freeing of the actual pages being a problem with speculative TLB > reloads, just the page-tables. The TLB on newer ARM cores can cache intermediate entries (e.g. pmd) as long as they are valid, even if the full translation is not possible (e.g. because the pte entry is 0). With fast_mode, this could lead to the MMU reading the already freed pte page as it was pointed at by the old pmd. Older ARMv7 CPUs (Cortex-A8), don't do this intermediate caching and UP should be fine with fast_mode==1 as we already track the pte range via tlb_remove_tlb_entry(). The MMU on ARM is treated like any another agent that accesses the memory, so standard memory ordering issues apply In theory Linux can clear the pmd, free the page and it is re-used shortly after while the MMU hasn't observed the pmd_clear() yet (we don't have a barrier in this function). > Should we introduce a tlb_remove_table() regardless of > HAVE_RCU_TABLE_FREE which always queues the tables regardless of > tlb_fast_mode()? This would probably work as well (or we just add support for HAVE_RCU_TABLE_FREE 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-05-17 12:15 UTC|newest] Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-03-02 17:59 [RFC][PATCH 0/6] mm: Unify TLB gather implementations Peter Zijlstra 2011-03-02 17:59 ` Peter Zijlstra 2011-03-02 17:59 ` Peter Zijlstra 2011-03-02 17:59 ` [RFC][PATCH 1/6] mm: Optimize fullmm TLB flushing Peter Zijlstra 2011-03-02 17:59 ` Peter Zijlstra 2011-03-02 17:59 ` Peter Zijlstra 2011-03-02 17:59 ` [RFC][PATCH 2/6] mm: Change flush_tlb_range() to take an mm_struct Peter Zijlstra 2011-03-02 17:59 ` Peter Zijlstra 2011-03-02 17:59 ` Peter Zijlstra 2011-03-02 19:19 ` Linus Torvalds 2011-03-02 19:19 ` Linus Torvalds 2011-03-02 20:58 ` Rik van Riel 2011-03-02 20:58 ` Rik van Riel 2011-03-02 21:40 ` Peter Zijlstra 2011-03-02 21:40 ` Peter Zijlstra 2011-03-02 21:47 ` David Miller 2011-03-02 21:47 ` David Miller 2011-03-03 17:22 ` Chris Metcalf 2011-03-03 17:22 ` Chris Metcalf 2011-03-03 17:22 ` Chris Metcalf 2011-03-03 18:45 ` David Miller 2011-03-03 18:45 ` David Miller 2011-03-03 18:56 ` Chris Metcalf 2011-03-03 18:56 ` Chris Metcalf 2011-03-03 18:56 ` Chris Metcalf 2011-03-10 18:05 ` [PATCH] arch/tile: optimize icache flush Chris Metcalf 2011-03-10 18:05 ` Chris Metcalf 2011-03-10 18:05 ` Chris Metcalf 2011-03-10 23:19 ` Rik van Riel 2011-03-10 23:19 ` Rik van Riel 2011-03-02 17:59 ` [RFC][PATCH 3/6] mm: Provide generic range tracking and flushing Peter Zijlstra 2011-03-02 17:59 ` Peter Zijlstra 2011-03-02 17:59 ` Peter Zijlstra 2011-03-02 17:59 ` [RFC][PATCH 4/6] arm, mm: Convert arm to generic tlb Peter Zijlstra 2011-03-02 17:59 ` Peter Zijlstra 2011-03-02 17:59 ` Peter Zijlstra 2011-03-09 15:16 ` Catalin Marinas 2011-03-09 15:16 ` Catalin Marinas 2011-03-09 15:19 ` Peter Zijlstra 2011-03-09 15:19 ` Peter Zijlstra 2011-03-09 15:36 ` Catalin Marinas 2011-03-09 15:36 ` Catalin Marinas 2011-03-09 15:39 ` Peter Zijlstra 2011-03-09 15:39 ` Peter Zijlstra 2011-03-09 15:48 ` Peter Zijlstra 2011-03-09 15:48 ` Peter Zijlstra 2011-03-09 16:34 ` Catalin Marinas 2011-03-09 16:34 ` Catalin Marinas 2012-05-17 3:05 ` Paul Mundt 2012-05-17 3:05 ` Paul Mundt 2012-05-17 9:30 ` Catalin Marinas 2012-05-17 9:30 ` Catalin Marinas 2012-05-17 9:39 ` Catalin Marinas 2012-05-17 9:39 ` Catalin Marinas 2012-05-17 9:51 ` Russell King 2012-05-17 9:51 ` Russell King 2012-05-17 11:28 ` Peter Zijlstra 2012-05-17 11:28 ` Peter Zijlstra 2012-05-17 12:14 ` Catalin Marinas [this message] 2012-05-17 12:14 ` Catalin Marinas 2012-05-17 16:00 ` Catalin Marinas 2012-05-17 16:00 ` Catalin Marinas 2012-05-17 16:24 ` Peter Zijlstra 2012-05-17 16:24 ` Peter Zijlstra 2012-05-17 16:33 ` Peter Zijlstra 2012-05-17 16:33 ` Peter Zijlstra 2012-05-17 16:44 ` Peter Zijlstra 2012-05-17 16:44 ` Peter Zijlstra 2012-05-17 16:59 ` Peter Zijlstra 2012-05-17 16:59 ` Peter Zijlstra 2012-05-17 17:01 ` Catalin Marinas 2012-05-17 17:01 ` Catalin Marinas 2012-05-17 17:11 ` Peter Zijlstra 2012-05-17 17:11 ` Peter Zijlstra 2012-05-21 7:47 ` Martin Schwidefsky 2012-05-21 7:47 ` Martin Schwidefsky 2012-05-17 17:22 ` Russell King 2012-05-17 17:22 ` Russell King 2012-05-17 18:31 ` Catalin Marinas 2012-05-17 18:31 ` Catalin Marinas 2011-03-02 17:59 ` [RFC][PATCH 5/6] ia64, mm: Convert ia64 " Peter Zijlstra 2011-03-02 17:59 ` Peter Zijlstra 2011-03-02 17:59 ` Peter Zijlstra 2011-03-02 17:59 ` [RFC][PATCH 6/6] sh, mm: Convert sh " Peter Zijlstra 2011-03-02 17:59 ` Peter Zijlstra 2011-03-02 17:59 ` Peter Zijlstra
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20120517121459.GA18593@arm.com \ --to=catalin.marinas@arm.com \ --cc=a.p.zijlstra@chello.nl \ --cc=aarcange@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=benh@kernel.crashing.org \ --cc=cmetcalf@tilera.com \ --cc=davem@davemloft.net \ --cc=hugh.dickins@tiscali.co.uk \ --cc=lethal@linux-sh.org \ --cc=linux-arch@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mel@csn.ul.ie \ --cc=mingo@elte.hu \ --cc=npiggin@kernel.dk \ --cc=riel@redhat.com \ --cc=rmk@arm.linux.org.uk \ --cc=schwidefsky@de.ibm.com \ --cc=tglx@linutronix.de \ --cc=torvalds@linux-foundation.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.