All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Nick Piggin <npiggin@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>,
	the arch/x86 maintainers <x86@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Nick Piggin <npiggin@kernel.dk>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Subject: Re: [PATCH 3/6] x86/ticketlock: Use C for __ticket_spin_unlock
Date: Mon, 24 Jan 2011 17:42:31 -0800	[thread overview]
Message-ID: <4D3E2A87.8010409@goop.org> (raw)
In-Reply-To: <AANLkTi=ZdDCYiUoZJHkxRsKyBjtTUmtWqzJOusZGwafO@mail.gmail.com>

On 01/24/2011 05:13 PM, Nick Piggin wrote:
> On Tue, Jan 25, 2011 at 10:41 AM, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
>> From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
>>
>> If we don't need to use a locked inc for unlock, then implement it in C.
>>
>> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
>> ---
>>  arch/x86/include/asm/spinlock.h |   32 +++++++++++++++++---------------
>>  1 files changed, 17 insertions(+), 15 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h
>> index f48a6e3..0170ba9 100644
>> --- a/arch/x86/include/asm/spinlock.h
>> +++ b/arch/x86/include/asm/spinlock.h
>> @@ -33,9 +33,21 @@
>>  * On PPro SMP or if we are using OOSTORE, we use a locked operation to unlock
>>  * (PPro errata 66, 92)
>>  */
>> -# define UNLOCK_LOCK_PREFIX LOCK_PREFIX
>> +static __always_inline void __ticket_unlock_release(struct arch_spinlock *lock)
>> +{
>> +       if (sizeof(lock->tickets.head) == sizeof(u8))
>> +               asm (LOCK_PREFIX "incb %0"
>> +                    : "+m" (lock->tickets.head) : : "memory");
>> +       else
>> +               asm (LOCK_PREFIX "incw %0"
>> +                    : "+m" (lock->tickets.head) : : "memory");
>> +
>> +}
>>  #else
>> -# define UNLOCK_LOCK_PREFIX
>> +static __always_inline void __ticket_unlock_release(struct arch_spinlock *lock)
>> +{
>> +       lock->tickets.head++;
>> +}
>>  #endif
>>
>>  /*
>> @@ -93,14 +105,6 @@ static __always_inline int __ticket_spin_trylock(arch_spinlock_t *lock)
>>
>>        return tmp;
>>  }
>> -
>> -static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock)
>> -{
>> -       asm volatile(UNLOCK_LOCK_PREFIX "incb %0"
>> -                    : "+m" (lock->slock)
>> -                    :
>> -                    : "memory", "cc");
>> -}
>>  #else
>>  static __always_inline void __ticket_spin_lock(arch_spinlock_t *lock)
>>  {
>> @@ -144,15 +148,13 @@ static __always_inline int __ticket_spin_trylock(arch_spinlock_t *lock)
>>
>>        return tmp;
>>  }
>> +#endif
>>
>>  static __always_inline void __ticket_spin_unlock(arch_spinlock_t *lock)
>>  {
>> -       asm volatile(UNLOCK_LOCK_PREFIX "incw %0"
>> -                    : "+m" (lock->slock)
>> -                    :
>> -                    : "memory", "cc");
>> +       __ticket_unlock_release(lock);
>> +       barrier();              /* prevent reordering into locked region */
>>  }
>> -#endif
> The barrier is wrong.

In what way?  Do you think it should be on the other side?

> What makes me a tiny bit uneasy is that gcc is allowed to implement
> this any way it wishes. OK there may be a NULL intersection of possible
> valid assembly which is a buggy unlock... but relying on gcc to implement
> lock primitives is scary. Does this really help in a way that can't be done
> with the assembly versions?

We rely on C/gcc for plenty of other subtle ordering things.  Spinlocks
aren't particularly special in this regard.

    J


  reply	other threads:[~2011-01-25  1:42 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-24 23:41 [PATCH 0/6] Clean up ticketlock implementation Jeremy Fitzhardinge
2011-01-24 23:41 ` [PATCH 1/6] x86/ticketlock: clean up types and accessors Jeremy Fitzhardinge
2011-01-24 23:41 ` [PATCH 2/6] x86/ticketlock: convert spin loop to C Jeremy Fitzhardinge
2011-01-24 23:41 ` [PATCH 3/6] x86/ticketlock: Use C for __ticket_spin_unlock Jeremy Fitzhardinge
2011-01-25  1:13   ` Nick Piggin
2011-01-25  1:42     ` Jeremy Fitzhardinge [this message]
2011-01-25  1:49       ` Nick Piggin
2011-01-24 23:41 ` [PATCH 4/6] x86/ticketlock: make large and small ticket versions of spin_lock the same Jeremy Fitzhardinge
2011-01-24 23:41 ` [PATCH 5/6] x86/ticketlock: make __ticket_spin_lock common Jeremy Fitzhardinge
2011-01-24 23:41 ` [PATCH 6/6] x86/ticketlock: make __ticket_spin_trylock common Jeremy Fitzhardinge
2011-01-25  1:16   ` Nick Piggin
2011-01-25  1:42     ` Jeremy Fitzhardinge
2011-01-25  1:58       ` Nick Piggin
2011-01-27 23:53         ` Jeremy Fitzhardinge
2011-01-25  1:08 ` [PATCH 0/6] Clean up ticketlock implementation Nick Piggin
2011-01-31 21:46   ` Jeremy Fitzhardinge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D3E2A87.8010409@goop.org \
    --to=jeremy@goop.org \
    --cc=hpa@zytor.com \
    --cc=jeremy.fitzhardinge@citrix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=npiggin@gmail.com \
    --cc=npiggin@kernel.dk \
    --cc=peterz@infradead.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.