Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <40948c12746cbef5d5c2262d69a157f9b609845b.camel@mengyan1223.wang>
Subject: Re: [PATCH] mips: remove reference to "newer Loongson-3"
From:   Xi Ruoyao <xry111@mengyan1223.wang>
To:     Jiaxun Yang <jiaxun.yang@flygoat.com>, linux-mips@vger.kernel.org
Cc:     Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
        linux-kernel@vger.kernel.org, Huacai Chen <chenhuacai@kernel.org>
Date:   Tue, 31 Aug 2021 00:25:17 +0800
In-Reply-To: <1d49da11-51d5-e148-cb02-9bd0ee57fae6@flygoat.com>
References: <0b7c9431efb12c2d957fcc53ec8f0743725d61b3.camel@mengyan1223.wang>
         <b32c0d64-77b2-d054-afcf-7d006eba3418@flygoat.com>
         <086f60d6ef4395db5da7ee22c4f352d5c901d396.camel@mengyan1223.wang>
         <1d49da11-51d5-e148-cb02-9bd0ee57fae6@flygoat.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.40.4 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

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