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 S933824AbcBBTam (ORCPT <rfc822;w@1wt.eu>);
	Tue, 2 Feb 2016 14:30:42 -0500
Received: from foss.arm.com ([217.140.101.70]:58226 "EHLO foss.arm.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1754894AbcBBTaj (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 2 Feb 2016 14:30:39 -0500
Date: Tue, 2 Feb 2016 19:30:38 +0000
From: Will Deacon <will.deacon@arm.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Boqun Feng <boqun.feng@gmail.com>,
        Paul McKenney <paulmck@linux.vnet.ibm.com>,
        Peter Zijlstra <peterz@infradead.org>,
        "Maciej W. Rozycki" <macro@imgtec.com>,
        David Daney <ddaney@caviumnetworks.com>,
        =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= <mans@mansr.com>,
        Ralf Baechle <ralf@linux-mips.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH] mips: Fix arch_spin_unlock()
Message-ID: <20160202193037.GQ10166@arm.com>
References: <20160201135621.GD6828@arm.com>
 <20160202035458.GF6719@linux.vnet.ibm.com>
 <20160202051904.GC1239@fixme-laptop.cn.ibm.com>
 <20160202064433.GG6719@linux.vnet.ibm.com>
 <CA+55aFyrZZYKK4hsRX6GTuJ0vxJ6uyVgb2i8mMuMoKE4JoS+jQ@mail.gmail.com>
 <CA+55aFwQ07x1ngSUEqqe7_6Kz2pY2+8rT5zamrQfubQhgHDKBw@mail.gmail.com>
 <20160202093440.GD1239@fixme-laptop.cn.ibm.com>
 <CA+55aFxBc8Phdbo44dLoAoF=eWXDqrgQzXjpj-_s_SK+aWAGag@mail.gmail.com>
 <20160202175127.GO10166@arm.com>
 <CA+55aFzNmkzKs7PS6O1MB3vWp0-NDdgxVFUQ-kGmkh5L1gk+4w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+55aFzNmkzKs7PS6O1MB3vWp0-NDdgxVFUQ-kGmkh5L1gk+4w@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Feb 02, 2016 at 10:06:36AM -0800, Linus Torvalds wrote:
> On Tue, Feb 2, 2016 at 9:51 AM, Will Deacon <will.deacon@arm.com> wrote:
> >
> > Given that the vast majority of weakly ordered architectures respect
> > address dependencies, I would expect all of them to be hurt if they
> > were forced to use barrier instructions instead, even those where the
> > microarchitecture is fairly strongly ordered in practice.
> 
> I do wonder if it would be all that noticeable, though. I don't think
> we've really had benchmarks.
> 
> For example, most of the RCU list traversal shows up on x86 - where
> loads are already acquires. But they show up not because of that, but
> because a RCU list traversal is pretty much always going to take the
> cache miss.
> 
> So it would actually be interesting to just try it - what happens to
> kernel-centric benchmarks (which are already fairly rare) on arm if we
> change the rcu_dereference() to be a smp_load_acquire()?
> 
> Because maybe nothing happens at all. I don't think we've ever tried it.

FWIW, and this is by no means conclusive, I hacked that up quickly and
ran hackbench a few times on the nearest idle arm64 system. The results
were consistently ~4% slower using acquire for rcu_dereference.

Will