From: Catalin Marinas <catalin.marinas@arm.com> To: "Russell King (Oracle)" <linux@armlinux.org.uk> Cc: Peter Zijlstra <peterz@infradead.org>, Andy Lutomirski <luto@kernel.org>, x86@kernel.org, Dave Hansen <dave.hansen@intel.com>, LKML <linux-kernel@vger.kernel.org>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, Nicholas Piggin <npiggin@gmail.com>, linux-arm-kernel@lists.infradead.org, Will Deacon <will@kernel.org> Subject: Re: [PATCH 7/8] membarrier: Remove arm (32) support for SYNC_CORE Date: Wed, 16 Jun 2021 16:45:29 +0100 [thread overview] Message-ID: <20210616154529.GD22433@arm.com> (raw) In-Reply-To: <20210616152326.GG22278@shell.armlinux.org.uk> On Wed, Jun 16, 2021 at 04:23:26PM +0100, Russell King wrote: > On Wed, Jun 16, 2021 at 04:04:56PM +0100, Catalin Marinas wrote: > > On Wed, Jun 16, 2021 at 02:22:27PM +0100, Russell King wrote: > > > If it's a problem, then it needs fixing. sys_cacheflush() is used to > > > implement GCC's __builtin___clear_cache(). I'm not sure who added this > > > to gcc. > > > > I'm surprised that it works. I guess it's just luck that the thread > > doing the code writing doesn't migrate before the sys_cacheflush() call. > > Maybe the platforms that use ARM MPCore avoid the issue somehow (maybe > by not using self-modifying code?) Not sure how widely it is/was used with JITs. In general, I think the systems at the time were quite tolerant to missing I-cache maintenance (maybe small caches?). We ran Linux for a while without 826cbdaff297 ("[ARM] 5092/1: Fix the I-cache invalidation on ARMv6 and later CPUs"). > > > Likely only in places where we care about I/D coherency - as the data > > > cache is required to be PIPT on these SMP platforms. > > > > We had similar issue with the cache maintenance for DMA. The hack we > > employed (in cache.S) is relying on the MESI protocol internals and > > forcing a read/write for ownership before the D-cache maintenance. > > Luckily ARM11MPCore doesn't do speculative data loads to trigger some > > migration back. > > That's very similar to the hack that was originally implemented for > MPCore DMA - see the DMA_CACHE_RWFO configuration option. Well, yes, that's what I wrote above ;) (I added the hack and config option IIRC). > An interesting point here is that cache_ops_need_broadcast() reads > MMFR3 bits 12..15, which in the MPCore TRM has nothing to with cache > operation broadcasting - but luckily is documented as containing zero. > So, cache_ops_need_broadcast() returns correctly (true) here. That's typical with any new feature. The 12..15 field was added in ARMv7 stating that cache maintenance is broadcast in hardware. Prior to this, the field was read-as-zero. So it's not luck but we could have avoided negating the meaning here, i.e. call it cache_ops_are_broadcast(). > > The simpler fix for flush_icache_range() is to disable preemption, read > > a word in a cacheline to force any dirty lines on another CPU to be > > evicted and then issue the D-cache maintenance (for those cache lines > > which are still dirty on the current CPU). > > Is just reading sufficient? If so, why do we do a read-then-write in > the MPCore DMA cache ops? Don't we need the write to force exclusive > ownership? If we don't have exclusive ownership of the dirty line, > how can we be sure to write it out of the caches? For cleaning (which is the case for I/D coherency), we only need reading since we are fine with clean lines being left in the D-cache on other CPUs. For invalidation, we indeed need to force the exclusive ownership, hence the write. -- Catalin
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com> To: "Russell King (Oracle)" <linux@armlinux.org.uk> Cc: Peter Zijlstra <peterz@infradead.org>, Andy Lutomirski <luto@kernel.org>, x86@kernel.org, Dave Hansen <dave.hansen@intel.com>, LKML <linux-kernel@vger.kernel.org>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>, Mathieu Desnoyers <mathieu.desnoyers@efficios.com>, Nicholas Piggin <npiggin@gmail.com>, linux-arm-kernel@lists.infradead.org, Will Deacon <will@kernel.org> Subject: Re: [PATCH 7/8] membarrier: Remove arm (32) support for SYNC_CORE Date: Wed, 16 Jun 2021 16:45:29 +0100 [thread overview] Message-ID: <20210616154529.GD22433@arm.com> (raw) In-Reply-To: <20210616152326.GG22278@shell.armlinux.org.uk> On Wed, Jun 16, 2021 at 04:23:26PM +0100, Russell King wrote: > On Wed, Jun 16, 2021 at 04:04:56PM +0100, Catalin Marinas wrote: > > On Wed, Jun 16, 2021 at 02:22:27PM +0100, Russell King wrote: > > > If it's a problem, then it needs fixing. sys_cacheflush() is used to > > > implement GCC's __builtin___clear_cache(). I'm not sure who added this > > > to gcc. > > > > I'm surprised that it works. I guess it's just luck that the thread > > doing the code writing doesn't migrate before the sys_cacheflush() call. > > Maybe the platforms that use ARM MPCore avoid the issue somehow (maybe > by not using self-modifying code?) Not sure how widely it is/was used with JITs. In general, I think the systems at the time were quite tolerant to missing I-cache maintenance (maybe small caches?). We ran Linux for a while without 826cbdaff297 ("[ARM] 5092/1: Fix the I-cache invalidation on ARMv6 and later CPUs"). > > > Likely only in places where we care about I/D coherency - as the data > > > cache is required to be PIPT on these SMP platforms. > > > > We had similar issue with the cache maintenance for DMA. The hack we > > employed (in cache.S) is relying on the MESI protocol internals and > > forcing a read/write for ownership before the D-cache maintenance. > > Luckily ARM11MPCore doesn't do speculative data loads to trigger some > > migration back. > > That's very similar to the hack that was originally implemented for > MPCore DMA - see the DMA_CACHE_RWFO configuration option. Well, yes, that's what I wrote above ;) (I added the hack and config option IIRC). > An interesting point here is that cache_ops_need_broadcast() reads > MMFR3 bits 12..15, which in the MPCore TRM has nothing to with cache > operation broadcasting - but luckily is documented as containing zero. > So, cache_ops_need_broadcast() returns correctly (true) here. That's typical with any new feature. The 12..15 field was added in ARMv7 stating that cache maintenance is broadcast in hardware. Prior to this, the field was read-as-zero. So it's not luck but we could have avoided negating the meaning here, i.e. call it cache_ops_are_broadcast(). > > The simpler fix for flush_icache_range() is to disable preemption, read > > a word in a cacheline to force any dirty lines on another CPU to be > > evicted and then issue the D-cache maintenance (for those cache lines > > which are still dirty on the current CPU). > > Is just reading sufficient? If so, why do we do a read-then-write in > the MPCore DMA cache ops? Don't we need the write to force exclusive > ownership? If we don't have exclusive ownership of the dirty line, > how can we be sure to write it out of the caches? For cleaning (which is the case for I/D coherency), we only need reading since we are fine with clean lines being left in the D-cache on other CPUs. For invalidation, we indeed need to force the exclusive ownership, hence the write. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-06-16 15:46 UTC|newest] Thread overview: 165+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-16 3:21 [PATCH 0/8] membarrier cleanups Andy Lutomirski 2021-06-16 3:21 ` [PATCH 1/8] membarrier: Document why membarrier() works Andy Lutomirski 2021-06-16 4:00 ` Nicholas Piggin 2021-06-16 7:30 ` Peter Zijlstra 2021-06-17 23:45 ` Andy Lutomirski 2021-06-16 3:21 ` [PATCH 2/8] x86/mm: Handle unlazying membarrier core sync in the arch code Andy Lutomirski 2021-06-16 4:25 ` Nicholas Piggin 2021-06-16 18:31 ` Andy Lutomirski 2021-06-16 17:49 ` Mathieu Desnoyers 2021-06-16 17:49 ` Mathieu Desnoyers 2021-06-16 18:31 ` Andy Lutomirski 2021-06-16 3:21 ` [PATCH 3/8] membarrier: Remove membarrier_arch_switch_mm() prototype in core code Andy Lutomirski 2021-06-16 4:26 ` Nicholas Piggin 2021-06-16 17:52 ` Mathieu Desnoyers 2021-06-16 17:52 ` Mathieu Desnoyers 2021-06-16 3:21 ` [PATCH 4/8] membarrier: Make the post-switch-mm barrier explicit Andy Lutomirski 2021-06-16 4:19 ` Nicholas Piggin 2021-06-16 7:35 ` Peter Zijlstra 2021-06-16 18:41 ` Andy Lutomirski 2021-06-17 1:37 ` Nicholas Piggin 2021-06-17 2:57 ` Andy Lutomirski 2021-06-17 5:32 ` Andy Lutomirski 2021-06-17 6:51 ` Nicholas Piggin 2021-06-17 23:49 ` Andy Lutomirski 2021-06-19 2:53 ` Nicholas Piggin 2021-06-19 3:20 ` Andy Lutomirski 2021-06-19 4:27 ` Nicholas Piggin 2021-06-17 9:08 ` [RFC][PATCH] sched: Use lightweight hazard pointers to grab lazy mms Peter Zijlstra 2021-06-17 9:10 ` Peter Zijlstra 2021-06-17 10:00 ` Nicholas Piggin 2021-06-17 9:13 ` Peter Zijlstra 2021-06-17 14:06 ` Andy Lutomirski 2021-06-17 9:28 ` Peter Zijlstra 2021-06-17 14:03 ` Andy Lutomirski 2021-06-17 14:10 ` Andy Lutomirski 2021-06-17 15:45 ` Peter Zijlstra 2021-06-18 3:29 ` Paul E. McKenney 2021-06-18 5:04 ` Andy Lutomirski 2021-06-17 15:02 ` [PATCH 4/8] membarrier: Make the post-switch-mm barrier explicit Paul E. McKenney 2021-06-18 0:06 ` Andy Lutomirski 2021-06-18 3:35 ` Paul E. McKenney 2021-06-17 8:45 ` Peter Zijlstra 2021-06-16 3:21 ` [PATCH 5/8] membarrier, kthread: Use _ONCE accessors for task->mm Andy Lutomirski 2021-06-16 4:28 ` Nicholas Piggin 2021-06-16 18:08 ` Mathieu Desnoyers 2021-06-16 18:08 ` Mathieu Desnoyers 2021-06-16 18:45 ` Andy Lutomirski 2021-06-16 3:21 ` [PATCH 6/8] powerpc/membarrier: Remove special barrier on mm switch Andy Lutomirski 2021-06-16 3:21 ` Andy Lutomirski 2021-06-16 4:36 ` Nicholas Piggin 2021-06-16 4:36 ` Nicholas Piggin 2021-06-16 3:21 ` [PATCH 7/8] membarrier: Remove arm (32) support for SYNC_CORE Andy Lutomirski 2021-06-16 3:21 ` Andy Lutomirski 2021-06-16 9:28 ` Russell King (Oracle) 2021-06-16 9:28 ` Russell King (Oracle) 2021-06-16 10:16 ` Peter Zijlstra 2021-06-16 10:16 ` Peter Zijlstra 2021-06-16 10:20 ` Peter Zijlstra 2021-06-16 10:20 ` Peter Zijlstra 2021-06-16 10:34 ` Russell King (Oracle) 2021-06-16 10:34 ` Russell King (Oracle) 2021-06-16 11:10 ` Peter Zijlstra 2021-06-16 11:10 ` Peter Zijlstra 2021-06-16 13:22 ` Russell King (Oracle) 2021-06-16 13:22 ` Russell King (Oracle) 2021-06-16 15:04 ` Catalin Marinas 2021-06-16 15:04 ` Catalin Marinas 2021-06-16 15:23 ` Russell King (Oracle) 2021-06-16 15:23 ` Russell King (Oracle) 2021-06-16 15:45 ` Catalin Marinas [this message] 2021-06-16 15:45 ` Catalin Marinas 2021-06-16 16:00 ` Catalin Marinas 2021-06-16 16:00 ` Catalin Marinas 2021-06-16 16:27 ` Russell King (Oracle) 2021-06-16 16:27 ` Russell King (Oracle) 2021-06-17 8:55 ` Krzysztof Hałasa 2021-06-17 8:55 ` Krzysztof Hałasa 2021-06-17 8:55 ` Krzysztof Hałasa 2021-06-18 12:54 ` Linus Walleij 2021-06-18 12:54 ` Linus Walleij 2021-06-18 12:54 ` Linus Walleij 2021-06-18 13:19 ` Russell King (Oracle) 2021-06-18 13:19 ` Russell King (Oracle) 2021-06-18 13:36 ` Arnd Bergmann 2021-06-18 13:36 ` Arnd Bergmann 2021-06-18 13:36 ` Arnd Bergmann 2021-06-17 10:40 ` Mark Rutland 2021-06-17 10:40 ` Mark Rutland 2021-06-17 11:23 ` Russell King (Oracle) 2021-06-17 11:23 ` Russell King (Oracle) 2021-06-17 11:33 ` Mark Rutland 2021-06-17 11:33 ` Mark Rutland 2021-06-17 13:41 ` Andy Lutomirski 2021-06-17 13:41 ` Andy Lutomirski 2021-06-17 13:51 ` Mark Rutland 2021-06-17 13:51 ` Mark Rutland 2021-06-17 14:00 ` Andy Lutomirski 2021-06-17 14:00 ` Andy Lutomirski 2021-06-17 14:20 ` Mark Rutland 2021-06-17 14:20 ` Mark Rutland 2021-06-17 15:01 ` Peter Zijlstra 2021-06-17 15:01 ` Peter Zijlstra 2021-06-17 15:13 ` Peter Zijlstra 2021-06-17 15:13 ` Peter Zijlstra 2021-06-17 14:16 ` Mathieu Desnoyers 2021-06-17 14:16 ` Mathieu Desnoyers 2021-06-17 14:05 ` Peter Zijlstra 2021-06-17 14:05 ` Peter Zijlstra 2021-06-18 0:07 ` Andy Lutomirski 2021-06-18 0:07 ` Andy Lutomirski 2021-06-16 3:21 ` [PATCH 8/8] membarrier: Rewrite sync_core_before_usermode() and improve documentation Andy Lutomirski 2021-06-16 3:21 ` Andy Lutomirski 2021-06-16 3:21 ` Andy Lutomirski 2021-06-16 4:45 ` Nicholas Piggin 2021-06-16 4:45 ` Nicholas Piggin 2021-06-16 4:45 ` Nicholas Piggin 2021-06-16 18:52 ` Andy Lutomirski 2021-06-16 18:52 ` Andy Lutomirski 2021-06-16 18:52 ` Andy Lutomirski 2021-06-16 23:48 ` Andy Lutomirski 2021-06-16 23:48 ` Andy Lutomirski 2021-06-16 23:48 ` Andy Lutomirski 2021-06-18 15:27 ` Christophe Leroy 2021-06-18 15:27 ` Christophe Leroy 2021-06-18 15:27 ` Christophe Leroy 2021-06-16 10:20 ` Will Deacon 2021-06-16 10:20 ` Will Deacon 2021-06-16 10:20 ` Will Deacon 2021-06-16 23:58 ` Andy Lutomirski 2021-06-16 23:58 ` Andy Lutomirski 2021-06-16 23:58 ` Andy Lutomirski 2021-06-17 14:47 ` Mathieu Desnoyers 2021-06-17 14:47 ` Mathieu Desnoyers 2021-06-17 14:47 ` Mathieu Desnoyers 2021-06-17 14:47 ` Mathieu Desnoyers 2021-06-18 0:12 ` Andy Lutomirski 2021-06-18 0:12 ` Andy Lutomirski 2021-06-18 0:12 ` Andy Lutomirski 2021-06-18 16:31 ` Mathieu Desnoyers 2021-06-18 16:31 ` Mathieu Desnoyers 2021-06-18 16:31 ` Mathieu Desnoyers 2021-06-18 16:31 ` Mathieu Desnoyers 2021-06-18 19:58 ` Andy Lutomirski 2021-06-18 19:58 ` Andy Lutomirski 2021-06-18 19:58 ` Andy Lutomirski 2021-06-18 20:09 ` Mathieu Desnoyers 2021-06-18 20:09 ` Mathieu Desnoyers 2021-06-18 20:09 ` Mathieu Desnoyers 2021-06-18 20:09 ` Mathieu Desnoyers 2021-06-19 6:02 ` Nicholas Piggin 2021-06-19 6:02 ` Nicholas Piggin 2021-06-19 6:02 ` Nicholas Piggin 2021-06-19 15:50 ` Andy Lutomirski 2021-06-19 15:50 ` Andy Lutomirski 2021-06-19 15:50 ` Andy Lutomirski 2021-06-20 2:10 ` Nicholas Piggin 2021-06-20 2:10 ` Nicholas Piggin 2021-06-20 2:10 ` Nicholas Piggin 2021-06-17 15:16 ` Mathieu Desnoyers 2021-06-17 15:16 ` Mathieu Desnoyers 2021-06-17 15:16 ` Mathieu Desnoyers 2021-06-17 15:16 ` Mathieu Desnoyers 2021-06-18 0:13 ` Andy Lutomirski 2021-06-18 0:13 ` Andy Lutomirski 2021-06-18 0:13 ` Andy Lutomirski
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=20210616154529.GD22433@arm.com \ --to=catalin.marinas@arm.com \ --cc=akpm@linux-foundation.org \ --cc=dave.hansen@intel.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux@armlinux.org.uk \ --cc=luto@kernel.org \ --cc=mathieu.desnoyers@efficios.com \ --cc=npiggin@gmail.com \ --cc=peterz@infradead.org \ --cc=will@kernel.org \ --cc=x86@kernel.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.