Re: [RFC][PATCH] mips: Fix arch_spin_unlock()

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>,
	"Måns Rullgård" <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()
Date: Wed, 3 Feb 2016 19:03:08 +0000	[thread overview]
Message-ID: <20160203190307.GB15852@arm.com> (raw)
In-Reply-To: <20160203133210.GC20217@arm.com>

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