[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1601271224550.5958@tp.orcam.me.uk>
Date: Wed, 27 Jan 2016 12:41:29 +0000
From: "Maciej W. Rozycki" <macro@...tec.com>
To: Will Deacon <will.deacon@....com>
CC: David Daney <ddaney@...iumnetworks.com>,
Måns Rullgård <mans@...sr.com>,
Peter Zijlstra <peterz@...radead.org>,
Ralf Baechle <ralf@...ux-mips.org>,
<linux-kernel@...r.kernel.org>,
Paul McKenney <paulmck@...ux.vnet.ibm.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
<boqun.feng@...il.com>
Subject: Re: [RFC][PATCH] mips: Fix arch_spin_unlock()
On Wed, 27 Jan 2016, Will Deacon wrote:
> > Overall I think it should be safe after all to use SYNC_RELEASE and other
> > modern lightweight barriers uncondtionally under the assumption that
> > architecture was meant to remain backward compatible. Even though it
> > might be possible someone would implement unusual semantics for the then
> > undefined `stype' values, I highly doubt it as it would be extra effort
> > and hardware logic space for no gain. We could try and reach architecture
> > overseers to double-check whether the `stype' encodings, somewhat
> > irregularly distributed, were indeed defined in a manner so as not to
> > clash with values implementers chose to use before rev. 2.61 of the
> > architecture specification.
>
> Do you know whether a SYNC 18 (RELEASE) followed in program order by a
> SYNC 17 (ACQUIRE) creates a full barrier (i.e. something like SYNC 16)?
By my reading of architecture specifications it does. Specifically
SYNC_RELEASE (18) applies to older loads and stores, and newer stores, and
SYNC_ACQUIRE (17) applies to older loads, and newer loads and stores. So
the two combined ought to be the equivalent to SYNC_MB (16), which applies
to both older and newer loads and stores. Of course care has to be taken
about what happens between SYNC_RELEASE and SYNC_ACQUIRE. This is still
more lightweight than classic SYNC (0). See the architecture documents,
e.g. the MIPS32 one[1] for details.
References:
[1] "MIPS Architecture For Programmers, Volume II-A: The MIPS32
Instruction Set", MIPS Technologies, Inc., Document Number: MD00086,
Revision 5.04, December 11, 2013, Table 4.7 "Encodings of the
Bits[10:6] of the SYNC instruction; the SType Field", p. 305
HTH,
Maciej
Powered by blists - more mailing lists