Re: [PATCH] mips: remove reference to "newer Loongson-3"

[Xi Ruoyao]

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@xxxxxxxxxxxxxxxx>
School of Aerospace Science and Technology, Xidian University