On Thu, 22 Dec 2005, Ingo Molnar wrote:
>
> * Nicolas Pitre <[email protected]> wrote:
>
> > [...] on ARMv6 at least this can be improved even further, but a
> > special implementation which is neither a fully qualified atomic
> > decrement nor an atomic swap is needed. [...]
>
> i'm curious, how would this ARMv6 solution look like, and what would be
> the advantages over the atomic swap based variant?
On ARMv6 (which can be SMP) the atomic swap instruction is much more
costly than on former ARM versions. It however has ll/sc instructions
which allows it to implement a true atomic decrement, and the lock fast
path would look like:
__mutex_lock:
1: ldrex r1, [r0]
sub r1, r1, #1
strex r2, r1, [r0]
cmp r2, #0
bne 1b
cmp r1, #0
moveq pc, lr
b __mutex_lock_failed
With my ARMv6 implementation of arch_mutex_fast_lock() then it would
become:
__mutex_lock:
ldrex r1, [r0]
sub r1, r1, #1
strex r2, r1, [r0]
orrs r0, r2, r1
moveq pc, lr
b __mutex_lock_failed
This code sequence is not possible with any of the standard atomic
primitives. And the above would work even for the
arch_mutex_fast_lock_retval() used for mutex_lock_interruptible.
Giving complete freedom to the architecture in implementing those could
benefit architectures where disabling preemption while performing the
lock instead of attempting any true atomic operation would be cheaper
(Linus argued about that previously). And if we are UP with preemption
disabled then the lock could possibly be simplified even further if
someone dare to.
But those implementation issues don't belong in the common core code at
all IMHO.
Nicolas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
