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 S965939AbcBCTDL (ORCPT <rfc822;w@1wt.eu>);
	Wed, 3 Feb 2016 14:03:11 -0500
Received: from foss.arm.com ([217.140.101.70]:37103 "EHLO foss.arm.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S965880AbcBCTDI (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 3 Feb 2016 14:03:08 -0500
Date: Wed, 3 Feb 2016 19:03:08 +0000
From: Will Deacon <will.deacon@arm.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
        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: <20160203190307.GB15852@arm.com>
References: <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>
 <20160202193037.GQ10166@arm.com>
 <20160203083338.GA1772@gmail.com>
 <20160203133210.GC20217@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160203133210.GC20217@arm.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 Wed, Feb 03, 2016 at 01:32:10PM +0000, Will Deacon wrote:
> On Wed, Feb 03, 2016 at 09:33:39AM +0100, Ingo Molnar wrote:
> > In fact I'd suggest to test this via a quick runtime hack like this in rcupdate.h:
> > 
> > 	extern int panic_timeout;
> > 
> > 	...
> > 
> > 	if (panic_timeout)
> > 		smp_load_acquire(p);
> > 	else
> > 		typeof(*p) *________p1 = (typeof(*p) *__force)lockless_dereference(p);
> > 
> > (or so)
> 
> So the problem with this is that a LOAD <ctrl> LOAD sequence isn't an
> ordering hazard on ARM, so you're potentially at the mercy of the branch
> predictor as to whether you get an acquire. That's not to say it won't
> be discarded as soon as the conditional is resolved, but it could
> screw up the benchmarking.
> 
> I'd be better off doing some runtime patching, but that's not something
> I can knock up in a couple of minutes (so I'll add it to my list).

... so I actually got that up and running, believe it or not. Filthy stuff.

The good news is that you're right, and I'm now seeing ~1% difference
between the runs with ~0.3% noise for either of them. I still think
that's significant, but it's a lot more reassuring than 4%.

Will