* Nick Piggin <[EMAIL PROTECTED]> wrote:
> Speed up generic mutex implementations.
>
> - atomic operations which both modify the variable and return something imply
> full smp memory barriers before and after the memory operations involved
> (failing atomic_cmpxchg, atomic_add_unless, etc don't imply a barrier
> because
> they don't modify the target). See Documentation/atomic_ops.txt.
> So remove extra barriers and branches.
>
> - All architectures support atomic_cmpxchg. This has no relation to
> __HAVE_ARCH_CMPXCHG. We can just take the atomic_cmpxchg path
> unconditionally
>
> This reduces a simple single threaded fastpath lock+unlock test from 590
> cycles
> to 203 cycles on a ppc970 system.
>
> Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
no objections here. Lets merge these two patches via the ppc tree, so
that it gets testing on real hardware as well?
Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
Ingo
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
