[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZjuUiHp4Qc7EzuOz@andrea>
Date: Wed, 8 May 2024 17:04:40 +0200
From: Andrea Parri <parri.andrea@...il.com>
To: Puranjay Mohan <puranjay@...nel.org>
Cc: Daniel Lustig <dlustig@...dia.com>, Will Deacon <will@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Boqun Feng <boqun.feng@...il.com>,
Mark Rutland <mark.rutland@....com>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>, linux-kernel@...r.kernel.org,
linux-riscv@...ts.infradead.org
Subject: Re: [PATCH] riscv/atomic.h: optimize ops with acquire/release
ordering
> From my understanding of the current version of the RV memory model:
>
> .aq provides .aq -> all ordering
> .rl provides all -> .rl ordering
> and because this is RCsc variant of release consistency
> .rl -> .aq
>
> which means
>
> R/W
> amoswap.w.rl
> amoswap.w.aq
> R/W
>
> Should act as a full fence? R/W -> rl -> aq -> R/W
Yes, hence the RCsc ("sc" for "sequential consistent") qualification.
> So, I will do the following now:
>
> 1. Do some benchmarking on real hardware and find out how much overhead
> these weak fences add.
> 2. Study the LKMM and the RVWMO for the next few weeks/months or however
> much time it takes me to confidently reason about things written in
> these two models.
> 3. Study the locking / related code of RISC-V to see what could break if
> we change all these operations in accordance with "Code Porting and
> Mapping Guidelines" of RISCV ISA.
> 4. I will use the herd7 models of LKMM and RVWMO and see if everything
> works as expected after these changes.
>
>
> And If I am convinced after all this, I will send a patch to implement
> "Code Porting and Mapping Guidelines" + provide performance numbers from
> real hardware.
>
> Thanks for the detailed explainations and especially regarding how the
> LKMM evolved.
Sounds good! Thanks.
Andrea
Powered by blists - more mailing lists