From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759330AbdKPKZt (ORCPT ); Thu, 16 Nov 2017 05:25:49 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:49040 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751152AbdKPKZi (ORCPT ); Thu, 16 Nov 2017 05:25:38 -0500 Date: Thu, 16 Nov 2017 10:25:46 +0000 From: Will Deacon To: Daniel Lustig Cc: Boqun Feng , Palmer Dabbelt , Arnd Bergmann , Olof Johansson , "linux-kernel@vger.kernel.org" , "patches@groups.riscv.org" , "peterz@infradead.org" Subject: Re: [patches] Re: [PATCH v9 05/12] RISC-V: Atomic and Locking Code Message-ID: <20171116102545.GA9361@arm.com> References: <20171115180600.GR19071@arm.com> <20171116011906.GE6280@tardis> <7af820e0b90848dbac4d3120758b1cf6@HQMAIL105.nvidia.com> <20171116015212.GF6280@tardis> <2965fc412451432db276d561d47902fb@HQMAIL105.nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2965fc412451432db276d561d47902fb@HQMAIL105.nvidia.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Daniel, On Thu, Nov 16, 2017 at 06:40:46AM +0000, Daniel Lustig wrote: > > > In that case, maybe we should just start out having a fence on both > > > sides for > > > > Actually, given your architecture is RCsc rather than RCpc, so I think maybe > > you could follow the way that ARM uses(i.e. relaxed load + release store + a > > full barrier). You can see the commit log of 8e86f0b409a4 > > ("arm64: atomics: fix use of acquire + release for full barrier > > semantics") for the reasoning: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/co > > mmit/?id=8e86f0b409a44193f1587e87b69c5dcf8f65be67 > > OK I'm catching up now...and I have to say, that is clever! Thanks for the > corrections. It would definitely be good to avoid the double fence. Let me > think this over a bit more. > > One subtle point about RCpc vs. RCsc, though: see below. > > > > > Sounds great! Any estimation when we can see that(maybe a draft)? > > The latest should be November 28-30, coinciding with the next RISC-V workshop. > Possibly even sooner. We just recently resolved a big debate that's been > holding us up for a while, and so now it's just a matter of me writing it all > up so it's understandable. > > In the meantime, though, let me quickly and informally summarize some of the > highlights, in case it helps unblock any further review here: > > - The model is now (other-)multi-copy atomic > - .aq and .rl alone mean RCpc > - .aqrl means RCsc That presents you with an interesting choice when implementing locks: do you use .aqrl for lock and unlokc and elide smp_mb__after_spinlock, or do you use .aq/.rl for lock/unlock respectively and emit a fence for smp_mb__after_spinlock? > - .aq applies only to the read part of an RMW > - .rl applies only to the write part of an RMW > - Syntactic dependencies are now respected Thanks for the update, even this brief summary is better than the current architecture document ;) > I recognize this isn't enough detail to do it proper justice, but we'll get the > full model out as soon as we can. Ok, I'll bite! Do you forbid LB? Will