From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752657AbbIAQsG (ORCPT ); Tue, 1 Sep 2015 12:48:06 -0400 Received: from foss.arm.com ([217.140.101.70]:33148 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750949AbbIAQsD (ORCPT ); Tue, 1 Sep 2015 12:48:03 -0400 Date: Tue, 1 Sep 2015 17:47:58 +0100 From: Will Deacon To: Peter Zijlstra Cc: Thomas Gleixner , Linus Torvalds , Oleg Nesterov , Paul McKenney , Ingo Molnar , "mtk.manpages@gmail.com" , "dvhart@infradead.org" , "dave@stgolabs.net" , "Vineet.Gupta1@synopsys.com" , "ralf@linux-mips.org" , "ddaney@caviumnetworks.com" , "linux-kernel@vger.kernel.org" Subject: Re: futex atomic vs ordering constraints Message-ID: <20150901164758.GM1612@arm.com> References: <20150826181659.GW16853@twins.programming.kicks-ass.net> <20150901163140.GK1612@arm.com> <20150901164247.GO16853@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150901164247.GO16853@twins.programming.kicks-ass.net> 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 On Tue, Sep 01, 2015 at 05:42:47PM +0100, Peter Zijlstra wrote: > On Tue, Sep 01, 2015 at 05:31:40PM +0100, Will Deacon wrote: > > On Wed, Aug 26, 2015 at 07:16:59PM +0100, Peter Zijlstra wrote: > > > I tried to keep this email short, but failed miserably at this. For > > > the TL;DR skip to the tail. > > > > [...] > > > > > There are a few options: > > > > > > 1) punt, mandate they're both fully ordered and stop thinking about it > > > > > > 2) make them both fully relaxed, rely on implied barriers and employ > > > smp_mb__{before,after}_atomic in key places > > > > > > Given the current state of things and that I don't really think there is > > > a compelling performance argument to be made for 2, I would suggest we > > > go with 1. > > > > I'd also go for (1). Since there is a userspace side to this, I'd *really* > > like to avoid a potential situation on arm64 where the kernel builds its > > side of the futex using barrier instructions (e.g. treat LDR + smp_mb() > > as acquire) and userspace builds its side out of native acquire/release > > instructions and the two end up interacting badly (for example, loss of > > SC). > > I thought your native acquire/release were RCsc, or is it that in > combination with the 'fancy' 'full' barrier of stlxr + dmb-ish something > goes sideways? Yeah, they don't interact nicely because you can lose the multi-copy atomicity guarantees you get from using either native acquire/release everywhere or explicit barriers everywhere. IRIW shows the failure if you use {DMB; STR} for the writers and LDAR for the readers. > But yes, unless Thomas has other plans, I'll go ahead and create some > patches to make sure everybody is fully ordered so we can forget about > it again. Sounds good to me! Will