From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1755889AbbIBRAZ (ORCPT <rfc822;w@1wt.eu>);
	Wed, 2 Sep 2015 13:00:25 -0400
Received: from casper.infradead.org ([85.118.1.10]:52537 "EHLO
	casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1755610AbbIBRAY (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 2 Sep 2015 13:00:24 -0400
Date: Wed, 2 Sep 2015 19:00:08 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: Chris Metcalf <cmetcalf@ezchip.com>
Cc: Thomas Gleixner <tglx@linutronix.de>, Will Deacon <will.deacon@arm.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Oleg Nesterov <oleg@redhat.com>,
        Paul McKenney <paulmck@linux.vnet.ibm.com>,
        Ingo Molnar <mingo@kernel.org>,
        "mtk.manpages@gmail.com" <mtk.manpages@gmail.com>,
        "dvhart@infradead.org" <dvhart@infradead.org>,
        "dave@stgolabs.net" <dave@stgolabs.net>,
        "Vineet.Gupta1@synopsys.com" <Vineet.Gupta1@synopsys.com>,
        "ralf@linux-mips.org" <ralf@linux-mips.org>,
        "ddaney@caviumnetworks.com" <ddaney@caviumnetworks.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        linux@arm.linux.org.uk, rth@twiddle.net
Subject: Re: futex atomic vs ordering constraints
Message-ID: <20150902170008.GU19282@twins.programming.kicks-ass.net>
References: <20150826181659.GW16853@twins.programming.kicks-ass.net>
 <20150901163140.GK1612@arm.com>
 <20150901164247.GO16853@twins.programming.kicks-ass.net>
 <alpine.DEB.2.11.1509012104350.15006@nanos>
 <20150902125555.GT16853@twins.programming.kicks-ass.net>
 <55E71F92.4000001@ezchip.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <55E71F92.4000001@ezchip.com>
User-Agent: Mutt/1.5.21 (2012-12-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Sep 02, 2015 at 12:10:58PM -0400, Chris Metcalf wrote:
> On 09/02/2015 08:55 AM, Peter Zijlstra wrote:
> >So here goes..
> >
> >Chris, I'm awfully sorry, but I seem to be Tile challenged.
> >
> >TileGX seems to define:
> >
> >#define smp_mb__before_atomic()	smp_mb()
> >#define smp_mb__after_atomic()	smp_mb()
> >
> >However, its atomic_add_return() implementation looks like:
> >
> >static inline int atomic_add_return(int i, atomic_t *v)
> >{
> >	int val;
> >	smp_mb();  /* barrier for proper semantics */
> >	val = __insn_fetchadd4((void *)&v->counter, i) + i;
> >	barrier();  /* the "+ i" above will wait on memory */
> >	return val;
> >}
> >
> >Which leaves me confused on smp_mb__after_atomic().
> 
> Are you concerned about whether it has proper memory
> barrier semantics already, i.e. full barriers before and after?
> In fact we do have a full barrier before, but then because of the
> "+ i" / "barrier()", we know that the only other operation since
> the previous mb(), namely the read of v->counter, has
> completed after the atomic operation.  As a result we can
> omit explicitly having a second barrier.
> 
> It does seem like all the current memory-order semantics are
> correct, unless I'm missing something!

So I'm reading that code like:

	MB
 [RmW]	ret = *val += i


So what is stopping later memory ops like:

   [R]	a = *foo
   [S]	*bar = b

>>From getting reordered with the RmW, like:

	MB

   [R]	a = *foo
   [S]	*bar = b

 [RmW]	ret = *val += i

Are you saying Tile does not reorder things like that? If so, why then
is smp_mb__after_atomic() a full mb(). If it does, I don't see how your
add_return is correct.

Alternatively I'm just confused..