Received-SPF: pass (google.com: domain of linux-kernel+bounces-173451-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Wed, 8 May 2024 17:04:40 +0200
From: Andrea Parri <parri.andrea@gmail.com>
To: Puranjay Mohan <puranjay@kernel.org>
Cc: Daniel Lustig <dlustig@nvidia.com>, Will Deacon <will@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>, linux-kernel@vger.kernel.org,
	linux-riscv@lists.infradead.org
Subject: Re: [PATCH] riscv/atomic.h: optimize ops with acquire/release
 ordering
Message-ID: <ZjuUiHp4Qc7EzuOz@andrea>
References: <20240505123340.38495-1-puranjay@kernel.org>
 <ZjgLAKlWC2HQzWfU@andrea>
 <mb61p4jb91zs1.fsf@kernel.org>
 <Zjqqu6RN1kRXw/WT@andrea>
 <mb61pttj8z9p9.fsf@kernel.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <mb61pttj8z9p9.fsf@kernel.org>

> 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