[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <40948c12746cbef5d5c2262d69a157f9b609845b.camel@mengyan1223.wang>
Date: Tue, 31 Aug 2021 00:25:17 +0800
From: Xi Ruoyao <xry111@...gyan1223.wang>
To: Jiaxun Yang <jiaxun.yang@...goat.com>, linux-mips@...r.kernel.org
Cc: Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
linux-kernel@...r.kernel.org, Huacai Chen <chenhuacai@...nel.org>
Subject: Re: [PATCH] mips: remove reference to "newer Loongson-3"
On Tue, 2021-08-31 at 00:14 +0800, Jiaxun Yang wrote:
>
>
> 在 2021/8/30 下午8:28, Xi Ruoyao 写道:
> > On Mon, 2021-08-30 at 10:32 +0800, Jiaxun Yang wrote:
> > > 在 2021/8/29 20:49, Xi Ruoyao 写道:
> > > > Newest Loongson-3 processors have moved to use LoongArch
> > > > architecture.
> > > > Sadly, the LL/SC issue is still existing on both latest
> > > > Loongson-3
> > > > processors using MIPS64 (Loongson-3A4000) and LoongArch
> > > > (Loongson-3A5000).
> > > LLSC is fixed on Loongson-3A4000 as per CPUCFG report.
> > If I don't enable LL/SC fix, GCC libgomp tests fail on both 3A4000
> > and
> > 3A5000 (using github.com/loongson/gcc for the latter) with "invalid
> > access to 0x00000049" or "0x00000005". This is a race condition: it
> > does not happen at all with OMP_NUM_THREADS=1, happens with about
> > 10%
> > possibility with OMP_NUM_THREADS=2, and about 90% possibility with
> > OMP_NUM_THREAD=4 (on 3A5000, on 3A4000 the possibility is lower).
> Apologize for the false report, yes, you are right. I had checked with
> Loongson guys
> and they confirmed that the workaround still needs to be applied to
> latest 3A4000
> processors, including 3A4000 for MIPS and 3A5000 for LoongArch.
>
> Though, the reason behind the workaround varies with the evaluation of
> their uArch,
> for GS464V based core, barrier is required as the uArch design allows
> regular load
> to be reordered after an atomic linked load, and that would break
> assumption of compiler
> atomic constraints.
> For GS464E, barrier is required to flush the Store Fill Buffer and
> land
> all the cachelines
> to L1 cache, otherwise a linked load to a cacheline located at SFB may
> cause deadlock.
>
> For original GS464, barrier is required to deal with some kind of
> pipeline hazard to
> ensure store condition won't be shorted to success.
This explains the different (mis)behavior of LL/SC on those uarchs. I
remember the original report of LL/SC issue said it can cause a deadlock
on earlier model of 3As, but I didn't observed any deadlock on 3A4000.
(That's I why didn't tried the workaround immediately after spotting
libgomp failure, but debugged the code from 00:00 AM to 04:00 :( )
Thanks for your detailed explanation!
> Patch LGTM. The config symbol looks ambiguous and I'd agree with your
> idea of renaming.
>
> Thanks,
>
> - Jiaxun
> > Or these are two different erratas and I misunderstand them as the
> > same one?
So basically this is true :). They just happen to share one workaround.
--
Xi Ruoyao <xry111@...gyan1223.wang>
School of Aerospace Science and Technology, Xidian University
Powered by blists - more mailing lists