24 Oct, 2008

1 commit

  • - 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
    Signed-off-by: Linus Torvalds

    Nick Piggin
     

09 Feb, 2008

1 commit


04 Oct, 2006

1 commit


01 Apr, 2006

1 commit

  • Turn some macros into inline functions and add proper type checking as
    well as being more readable. Also a minor comment adjustment.

    Signed-off-by: Nicolas Pitre
    Acked-by: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Nicolas Pitre
     

10 Jan, 2006

1 commit

  • Add three (generic) mutex fastpath implementations.

    The mutex-xchg.h implementation is atomic_xchg() based, and should
    work fine on every architecture.

    The mutex-dec.h implementation is atomic_dec_return() based - this
    one too should work on every architecture, but might not perform the
    most optimally on architectures that have no atomic-dec/inc instructions.

    The mutex-null.h implementation forces all calls into the slowpath. This
    is used for mutex debugging, but it can also be used on platforms that do
    not want (or need) a fastpath at all.

    Signed-off-by: Ingo Molnar
    Signed-off-by: Arjan van de Ven

    Ingo Molnar