lkml.org 
[lkml]   [2005]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: About a change to the implementation of spin lock in 2.6.12 kernel.
Date
Hi Willy,

I think at least I can remove the LOCK instruction when the lock is already
held by someone else and enter the spinning wait directly, right?
0: cmpb $0, slp

jle 2f # lock is not available, then spinning
directly without locking the bus

1: lock; decb slp # lock the bus and atomically decrement

jns 3f # if clear sign bit jump forward to 3

2: pause # spin - wait

cmpb $0,slp # spin - compare to 0

jle 2b # spin - go back to 2 if <= 0 (locked)

jmp 1b # unlocked; go back to 1 to try to lock again

3: # we have acquired the lock .

But based on the Lockmeter report, the lock success is dominant 99.8%, so
maybe this will not make much change.
Thanks,

Liang

----- Original Message -----
From: "Willy Tarreau" <willy@w.ods.org>
To: <multisyncfe991@hotmail.com>
Cc: <linux-kernel@vger.kernel.org>
Sent: Wednesday, July 13, 2005 10:16 PM
Subject: Re: About a change to the implementation of spin lock in 2.6.12
kernel.


> Hi,
>
> On Wed, Jul 13, 2005 at 07:20:06PM -0700, multisyncfe991@hotmail.com
> wrote:
>> Hi,
>>
>> I found _spin_lock used a LOCK instruction to make the following
>> operation "decb %0" atomic. As you know, LOCK instruction alone takes
>> almost 70 clock cycles to finish and this add lots of cost to the
>> _spin_lock. However _spin_unlock does not use this LOCK instruction and
>> it uses "movb $1,%0" instead since 4-byte writes on 4-byte aligned
>> addresses are atomic.
>
> _spin_unlock does not need locked operations because when it is run, the
> code is already known to be the only one to hold the lock, so it can
> release it without checking what others do.
>
>> So I want rewrite the _spin_lock defined spinlock.h
>> (/linux/include/asm-i386) as follows to reduce the overhead of _spin_lock
>> and make it more efficient.
>
> It does not work. You cannot write an inter-cpu atomic test-and-set with
> several unlocked instructions.
>
>> #define spin_lock_string \
>> "\n1:\t" \
>> "cmpb $0,%0\n\t" \
>> "jle 2f\n\t" \
>
> ==> here, another thread or CPU can get the lock simultaneously.
>
>> "movb $0, %0\n\t" \
>> "jmp 3f\n" \
>> "2:\t" \
>> "rep;nop\n\t" \
>> "cmpb $0, %0\n\t" \
>> "jle 2b\n\t" \
>> "jmp 1b\n" \
>> "3:\n\t"
>>
>> Compared with the original version as follows, LOCK instruction is
>> removed. I rebuilt the Intel e1000 Gigabit driver with this _spin_lock.
>> There is about 2% throughput improvement.
>> #define spin_lock_string \
>> "\n1:\t" \
>> "lock ; decb %0\n\t" \
>> "jns 3f\n" \
>> "2:\t" \
>> "rep;nop\n\t" \
>> "cmpb $0,%0\n\t" \
>> "jle 2b\n\t" \
>> "jmp 1b\n" \
>> "3:\n\t"
>>
>> Do you think I can get a better performance if I dig further?
>>
>> Any ideas will be greatly appreciated,
>
> well, of course with those methods you can improve performance, but you
> lose the warranty that you're alone to get a lock, and that's bad.
>
> another similar method to get a lock in some very controlled environment
> is as follows :
>
> 1: cmp $0, %0
> jne 1b
> mov $CPUID, %0
> membar
> cmp $CPUID, %0
> jne 1b
>
> This only works with same speed CPUs and interrupts disabled. But in
> todays
> environments, this is very risky (hyperthreaded CPUs, etc...). However,
> this
> is often OK for more deterministic CPUs such as microcontrollers.
>
> Regards,
> Willy
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-07-14 18:27    [W:0.259 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site