[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEg0e7j1AvzTyaQ45wUP9QnsMpCG=ZMzcLNFYhGPPSgAwsty6A@mail.gmail.com>
Date: Fri, 24 Nov 2023 11:53:06 +0100
From: Christoph Müllner <christoph.muellner@...ll.eu>
To: Peter Zijlstra <peterz@...radead.org>
Cc: 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 11:15 AM Peter Zijlstra <peterz@...radead.org> wrote:
>
> On Fri, Nov 24, 2023 at 08:21:37AM +0100, Christoph Muellner wrote:
> > From: Christoph Müllner <christoph.muellner@...ll.eu>
> >
> > The upcoming RISC-V Ssdtso specification introduces a bit in the senvcfg
> > CSR to switch the memory consistency model at run-time from RVWMO to TSO
> > (and back). The active consistency model can therefore be switched on a
> > per-hart base and managed by the kernel on a per-process/thread base.
>
> You guys, computers are hartless, nobody told ya?
That's why they came up with RISC-V, the ISA with hart!
> > This patch implements basic Ssdtso support and adds a prctl API on top
> > so that user-space processes can switch to a stronger memory consistency
> > model (than the kernel was written for) at run-time.
> >
> > I am not sure if other architectures support switching the memory
> > consistency model at run-time, but designing the prctl API in an
> > arch-independent way allows reusing it in the future.
>
> IIRC some Sparc chips could do this, but I don't think anybody ever
> exposed this to userspace (or used it much).
>
> IA64 had planned to do this, except they messed it up and did it the
> wrong way around (strong first and then relax it later), which lead to
> the discovery that all existing software broke (d'uh).
>
> 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).
>
> IIRC Risc-V actually has such instructions as well, so *why* are you
> doing this?!?!
Not needing a transpiler is already a benefit.
And the DTSO approach also covers the cases where transpilers can't be used
(e.g. binary-only executables or libraries).
We are also working on extending ld.so such, that it switches to DTSO
(if available) in case the user wants to start an executable that was
compiled for Ztso or loads a library that was compiled for Ztso.
This would utilize the API that is introduced in this patchset.
Powered by blists - more mailing lists