[ltt-dev] Sparc64 support added to Userspace RCU

Mathieu Desnoyers mathieu.desnoyers at polymtl.ca
Thu Oct 22 15:57:53 EDT 2009

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:


Direct links:

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

Feedback is welcome,



* 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

More information about the lttng-dev mailing list