[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210616160050.GE22433@arm.com>
Date: Wed, 16 Jun 2021 17:00:51 +0100
From: Catalin Marinas <catalin.marinas@....com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Peter Zijlstra <peterz@...radead.org>,
Andy Lutomirski <luto@...nel.org>, x86@...nel.org,
Dave Hansen <dave.hansen@...el.com>,
LKML <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
Andrew Morton <akpm@...ux-foundation.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Nicholas Piggin <npiggin@...il.com>,
linux-arm-kernel@...ts.infradead.org, Will Deacon <will@...nel.org>
Subject: Re: [PATCH 7/8] membarrier: Remove arm (32) support for SYNC_CORE
On Wed, Jun 16, 2021 at 04:45:29PM +0100, Catalin Marinas wrote:
> 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:
> > > 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.
Ah, I'm not sure the I-cache is broadcast in hardware on ARM11MPCore
either. So fixing the D side won't be sufficient.
--
Catalin
Powered by blists - more mailing lists