lkml.org 
[lkml]   [1999]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: spin_unlock optimization(i386)
"Richard B. Johnson" wrote:
>
> On Sat, 20 Nov 1999, Manfred Spraul wrote:
>
> > the current spin_unlock asm code is
> > "lock; btrl $0,%0"
> > it takes ~ 22 ticks on my PII/350.
> >
> > I think it's possible to replace that with
> > "movl $0,%0"
> > which would be a simple, pairable single-tick instruction.
>
> Erm.... What about SMP machines? Are you going to get rid of them?
> The purpose of the lock prefix is not to make the current CPU operation
> atomic. It's to make all other CPUs halt until the operation is complete.
> This gurantees that only one CPU modifies the variable at the same
> time. You are not going to do that with a move.
>
I'm only talking about the _unlock_, obviously spin_lock() must use the
lock
prefix, and spin_lock needs a full memory barrier:
unlock means that you own the lock, and that all other CPUs are waiting,
and: we know the current value of spinlock_t.lock:

lock;btrl means
cpu pull LOCK
cpu reads spinlock_t.lock (always 0x0000 0001)
cpu clears bit 0, and updates the carry flag
cpu writes spinlock_t.lock (always 0x0000 0000)
cpu releases LOCK

mov means
cpu writes spinlock_t.lock (always 0x0)

memory writes to 32-bit values are always atomic (and atomic_set()
relies on this)
--> the only difference is the memory ordering.

--
Manfred

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:1.589 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site