From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753470AbbIAQnF (ORCPT ); Tue, 1 Sep 2015 12:43:05 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:48958 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751172AbbIAQnD (ORCPT ); Tue, 1 Sep 2015 12:43:03 -0400 Date: Tue, 1 Sep 2015 18:42:47 +0200 From: Peter Zijlstra To: Will Deacon 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: <20150901164247.GO16853@twins.programming.kicks-ass.net> References: <20150826181659.GW16853@twins.programming.kicks-ass.net> <20150901163140.GK1612@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150901163140.GK1612@arm.com> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 01, 2015 at 05:31:40PM +0100, Will Deacon wrote: > Hi Peter, > > 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? 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.