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
