[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231124115430.GS3818@noisy.programming.kicks-ass.net>
Date: Fri, 24 Nov 2023 12:54:30 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Jonas Oberhauser <jonas.oberhauser@...weicloud.com>
Cc: Christoph Muellner <christoph.muellner@...ll.eu>,
linux-riscv@...ts.infradead.org, linux-kselftest@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
Palmer Dabbelt <palmer@...belt.com>,
Paul Walmsley <paul.walmsley@...ive.com>,
Albert Ou <aou@...s.berkeley.edu>,
Andrew Morton <akpm@...ux-foundation.org>,
Shuah Khan <shuah@...nel.org>,
Jonathan Corbet <corbet@....net>,
Anup Patel <apatel@...tanamicro.com>,
Philipp Tomsich <philipp.tomsich@...ll.eu>,
Andrew Jones <ajones@...tanamicro.com>,
Guo Ren <guoren@...nel.org>,
Daniel Henrique Barboza <dbarboza@...tanamicro.com>,
Conor Dooley <conor.dooley@...rochip.com>,
Björn Töpel <bjorn@...osinc.com>,
Alan Stern <stern@...land.harvard.edu>,
Andrea Parri <parri.andrea@...il.com>,
Will Deacon <will@...nel.org>,
Daniel Lustig <dlustig@...dia.com>
Subject: Re: [RFC PATCH 0/5] RISC-V: Add dynamic TSO support
On Fri, Nov 24, 2023 at 12:04:09PM +0100, Jonas Oberhauser wrote:
> > I think ARM64 approached this problem by adding the
> > load-acquire/store-release instructions and for TSO based code,
> > translate into those (eg. x86 -> arm64 transpilers).
>
>
> Although those instructions have a bit more ordering constraints.
>
> I have heard rumors that the apple chips also have a register that can be
> set at runtime.
Oh, I thought they made do with the load-acquire/store-release thingies.
But to be fair, I haven't been paying *that* much attention to the apple
stuff.
I did read about how they fudged some of the x86 flags thing.
> And there are some IBM machines that have a setting, but not sure how it is
> controlled.
Cute, I'm assuming this is the Power series (s390 already being TSO)? I
wasn't aware they had this.
> > IIRC Risc-V actually has such instructions as well, so *why* are you
> > doing this?!?!
>
>
> Unfortunately, at least last time I checked RISC-V still hadn't gotten such
> instructions.
> What they have is the *semantics* of the instructions, but no actual opcodes
> to encode them.
Well, that sucks..
> I argued for them in the RISC-V memory group, but it was considered to be
> outside the scope of that group.
>
> Transpiling with sufficient DMB ISH to get the desired ordering is really
> bad for performance.
Ha!, quite dreadful I would imagine.
> That is not to say that linux should support this. Perhaps linux should
> pressure RISC-V into supporting implicit barriers instead.
I'm not sure I count for much in this regard, but yeah, that sounds like
a plan :-)
Powered by blists - more mailing lists