[lkml]   [2005]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 0/8] mutex subsystem, ANNOUNCE
    On Wed, 21 Dec 2005, Ingo Molnar wrote:

    > Changes since the previous version:
    > - removed the fastpath dependency on __HAVE_ARCH_CMPXCHG: now every
    > architecture is able to use the generic mutex_lock/mutex_unlock
    > lockless fastpath. The quality of the fastpath is still as good as in
    > the previous version.
    > - added ARCH_IMPLEMENTS_MUTEX_FASTPATH for architectures that want to
    > hand-code their own fastpath. The mutex_lock_slowpath,
    > mutex_unlock_slowpath and mutex_lock_interruptible_slowpath global
    > functions can be used by such architectures in this case, and they
    > should implement the mutex_lock(), mutex_unlock() and
    > mutex_lock_interruptible() functions themselves. I have tested this
    > mechanism on x86. (but x86 wants to use the generic functions
    > otherwise, so those changes are not included in this patchqueue.)

    This is a good step in the right direction for ARM, but not quite there

    As it is, the core mutex code is still relying on atomic
    decrement/increment to work properly. What would be extremely
    beneficial on ARM is to be able to use (variants of) atomic_xchg
    everywhere. And the semantics of a mutex allows that where a semaphore
    doesn't (which is why I see big benefits for ARM with mutexes).

    I even forsee a fast path implementation on ARMv6 that would use an
    hybrid approach which will be less instructions and cycles than a
    standard atomic decrement/increment (they are available only on ARM
    version 6 and above).

    What we'd need is a bit more flexibility but only at the low level. No
    need to reimplement the whole of mutex_lock(), mutex_unlock(), and

    Please consider the 3 following patches that already bring an immediate
    benefit on ARM, even if the fast path isn't inlined yet.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-12-21 23:46    [W:0.030 / U:10.748 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site