[ltt-dev] Sparc64 support added to Userspace RCU

[Mathieu Desnoyers]

By the way, I just added sparc64 support to the Userspace RCU library,
available at: git://lttng.org/userspace-rcu.git

Interesting files concerning sparc64 are:

urcu/arch_sparc64.h
urcu/uatomic_arch_sparc64.h

Direct links:
http://www.lttng.org/cgi-bin/gitweb.cgi?p=userspace-rcu.git;a=blob;f=urcu/arch_sparc64.h;hb=HEAD
http://www.lttng.org/cgi-bin/gitweb.cgi?p=userspace-rcu.git;a=blob;f=urcu/uatomic_arch_sparc64.h;hb=HEAD

Please note that this code targets user-space, not kernel-space.

Feedback is welcome,

Thanks,

Mathieu

* Mathieu Desnoyers (mathieu.desnoyers at polymtl.ca) wrote:
> Hi David,
> 
> I took a look at the current sparc64 cmpxchg implementation in the Linux
> kernel and stumbled on this commit:
> 
> commit 293666b7a17cb7a389fc274980439212386a19c4
> Author: David S. Miller <davem at davemloft.net>
> Date:   Sat Nov 15 13:33:25 2008 -0800
> 
>     sparc64: Stop using memory barriers for atomics and locks.
>     
>     The kernel always executes in the TSO memory model now,
>     so none of this stuff is necessary any more.
>     
>     With helpful feedback from Nick Piggin.
>     
>     Signed-off-by: David S. Miller <davem at davemloft.net>
> 
> Reading p. 152 A.9 Compare and Swap, I see that the cas instruction does
> not imply a memory barrier.
> 
> Reading http://docs.sun.com/app/docs/doc/801-6678/6i11oelck?a=view
> 
> I see that:
> 
> "TSO guarantees that the store, FLUSH, and atomic load-store
> instructions of all processors appear to be executed by memory serially
> in a single order called the memory order. Furthermore, the sequence of
> store, FLUSH, and atomic load-store instructions in the memory order for
> a given processor is identical to the sequence in which they were issued
> by the processor."
> 
> So it provides no guarantee whatsoever wrt loads. However, reading
> Documentation/memory-barriers.txt:
> 
> "Whilst they are technically interprocessor interaction considerations,
> atomic operations are noted specially as some of them imply full memory
> barriers and some don't, but they're very heavily relied on as a group
> throughout the kernel." -> cmpxchg is part of them.
> 
> The same applies to the other atomic instructions we find in this list.
> How is the correct ordering of loads wrt to cmxchg (and other atomic
> ops) still ensured by this modification?
> 
> Thanks,
> 
> Mathieu
> 
> -- 
> Mathieu Desnoyers
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68