[RFC] Fix SPARC atomic_write_barrier.

  This patch changes SPARC write barriers to be just release barriers.  I
haven't tested this, so this is based on my understanding of the SPARC
memory model (TSO).

For a release barrier, we have code like
  foo = 1;
  atomic_write_barrier ();
  release_flag = 1;
and release_flag could also be a spinlock unlock, for example.

So we want to prevent store/store and load/store reordering, so that the
release_flag assigment is the "last" thing.

Previously, the write barriers prevented -- AFAIU SPARC assembly --
store/load reordering, which is what you'd need a full barrier for on
TSO (e.g., consider Dekker synchronization).  The other kinds of
reordering barriers (e.g., load/store) are implicit on TSO (as on x86).
Thus, the change doesn't fix a correctness issue (at least if using
TSO!) but just a performance issue.

Could someone who cares about SPARC please review and test this?
  

From: Torvald Riegel <triegel@redhat.com>
Date: Thu, 30 Oct 2014 22:07:00 +0100

> This patch changes SPARC write barriers to be just release barriers.  I
> haven't tested this, so this is based on my understanding of the SPARC
> memory model (TSO).

The sparc memory model is variable.

It can be TSO, PSO, or RMO.

It is controlled by a bit in the processor state register, and not
all cpus support all memory models.

Linux happens to run all threads in TSO currently, but this is not
something GLIBC or any userland code should really depend upon.

So we should use whatever memory barriers are necessary in the least
strict memory model possible, which is RMO.
  

On Thu, 2014-10-30 at 19:08 -0400, David Miller wrote:
> From: Torvald Riegel <triegel@redhat.com>
> Date: Thu, 30 Oct 2014 22:07:00 +0100
> 
> > This patch changes SPARC write barriers to be just release barriers.  I
> > haven't tested this, so this is based on my understanding of the SPARC
> > memory model (TSO).
> 
> The sparc memory model is variable.
> 
> It can be TSO, PSO, or RMO.
> 
> It is controlled by a bit in the processor state register, and not
> all cpus support all memory models.
> 
> Linux happens to run all threads in TSO currently, but this is not
> something GLIBC or any userland code should really depend upon.
> 
> So we should use whatever memory barriers are necessary in the least
> strict memory model possible, which is RMO.

The patch doesn't rely on TSO.  If you consider RMO, then it could be
considered a bug fix because LoadStore was missing from the release
barrier.

With "my understanding of the SPARC memory model" I was referring to the
assumption that on TSO, acquire and release barriers are no-ops,
effectively, because the reordering constraints that make up the
barriers are implicitly provided.  And StoreLoad is not, but was part of
the release barrier, so this seemed to be a mistake.

Do you have an opinion on the actual patch, rather than my description?
  

From: Torvald Riegel <triegel@redhat.com>
Date: Fri, 31 Oct 2014 01:22:16 +0100

> Do you have an opinion on the actual patch, rather than my description?

Sorry for getting distracted :-) I'll review your patch as soon as I
can.
  

From: David Miller <davem@davemloft.net>
Date: Thu, 30 Oct 2014 21:58:34 -0400 (EDT)

> From: Torvald Riegel <triegel@redhat.com>
> Date: Fri, 31 Oct 2014 01:22:16 +0100
> 
>> Do you have an opinion on the actual patch, rather than my description?
> 
> Sorry for getting distracted :-) I'll review your patch as soon as I
> can.

It looks good, and passes the tests I've done so far.

Please feel free to commit it.

Thanks!