From: Jeremy Fitzhardinge <jeremy@goop.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Nick Piggin <npiggin@suse.de>,
Peter Zijlstra <peterz@infradead.org>,
Xen-devel <xen-devel@lists.xensource.com>,
Avi Kivity <avi@redhat.com>, Jan Beulich <JBeulich@novell.com>
Subject: Re: [Xen-devel] [PATCH RFC 03/12] x86/ticketlock: Use C for __ticket_spin_unlock
Date: Fri, 06 Aug 2010 13:03:00 -0700 [thread overview]
Message-ID: <4C5C6A74.1050106@goop.org> (raw)
In-Reply-To: <4C5C4AAB.3000606@zytor.com>
On 08/06/2010 10:47 AM, H. Peter Anvin wrote:
> On 07/20/2010 09:17 AM, Jeremy Fitzhardinge wrote:
>> "volatile" would be a compiler barrier, but it has no direct effect on,
>> or relevence to, the CPU. It just cares about the LOCK_PREFIX. The
>> "memory" clobber is probably unnecessary as well, since the constraints
>> already tell the compiler the most important information. We can add
>> barriers separately as needed.
>>
> You absolutely need volatile, since otherwise you're permitting the
> compiler to split, re-execute or even drop the code. Anything else
> might work, by accident, but it's not clean.
I don't think so in this case. The instructions in question are
basically lock->waiters++/--; the only reason they need to be asm is
that they're locked. But I'm not relying on them for any kind of
compiler or cpu ordering or barrier. Where ordering is important, I
have explicit barrier()s to enforce it.
J
WARNING: multiple messages have this Message-ID (diff)
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Nick Piggin <npiggin@suse.de>,
Xen-devel <xen-devel@lists.xensource.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Peter Zijlstra <peterz@infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Jan Beulich <JBeulich@novell.com>, Avi Kivity <avi@redhat.com>
Subject: Re: [PATCH RFC 03/12] x86/ticketlock: Use C for __ticket_spin_unlock
Date: Fri, 06 Aug 2010 13:03:00 -0700 [thread overview]
Message-ID: <4C5C6A74.1050106@goop.org> (raw)
In-Reply-To: <4C5C4AAB.3000606@zytor.com>
On 08/06/2010 10:47 AM, H. Peter Anvin wrote:
> On 07/20/2010 09:17 AM, Jeremy Fitzhardinge wrote:
>> "volatile" would be a compiler barrier, but it has no direct effect on,
>> or relevence to, the CPU. It just cares about the LOCK_PREFIX. The
>> "memory" clobber is probably unnecessary as well, since the constraints
>> already tell the compiler the most important information. We can add
>> barriers separately as needed.
>>
> You absolutely need volatile, since otherwise you're permitting the
> compiler to split, re-execute or even drop the code. Anything else
> might work, by accident, but it's not clean.
I don't think so in this case. The instructions in question are
basically lock->waiters++/--; the only reason they need to be asm is
that they're locked. But I'm not relying on them for any kind of
compiler or cpu ordering or barrier. Where ordering is important, I
have explicit barrier()s to enforce it.
J
next prev parent reply other threads:[~2010-08-06 20:03 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-17 1:03 [PATCH RFC 00/12] X86 ticket lock cleanups and improvements Jeremy Fitzhardinge
2010-07-17 1:03 ` [PATCH RFC 06/12] x86/ticketlock: make __ticket_spin_trylock common Jeremy Fitzhardinge
2010-07-17 1:03 ` [PATCH RFC 04/12] x86/ticketlock: make large and small ticket versions of spin_lock the same Jeremy Fitzhardinge
2010-07-17 1:03 ` [PATCH RFC 11/12] x86/pvticketlock: use callee-save for lock_spinning Jeremy Fitzhardinge
2010-07-17 1:03 ` [PATCH RFC 12/12] x86/pvticketlock: use callee-save for unlock_kick as well Jeremy Fitzhardinge
2010-07-17 1:03 ` [PATCH RFC 08/12] x86/ticketlock: collapse a layer of functions Jeremy Fitzhardinge
2010-07-17 1:03 ` [PATCH RFC 02/12] x86/ticketlock: convert spin loop to C Jeremy Fitzhardinge
2010-08-02 15:07 ` Peter Zijlstra
2010-08-02 15:17 ` Jeremy Fitzhardinge
2010-08-02 15:17 ` Jeremy Fitzhardinge
2010-08-06 12:43 ` Jan Beulich
2010-08-06 14:53 ` Jeremy Fitzhardinge
2010-08-06 20:17 ` H. Peter Anvin
2010-08-06 20:17 ` H. Peter Anvin
2010-08-06 20:33 ` Jeremy Fitzhardinge
2010-08-06 20:33 ` Jeremy Fitzhardinge
2010-08-06 21:09 ` H. Peter Anvin
2010-08-06 21:09 ` H. Peter Anvin
2010-08-06 22:03 ` Jeremy Fitzhardinge
2010-07-17 1:03 ` [PATCH RFC 01/12] x86/ticketlock: clean up types and accessors Jeremy Fitzhardinge
2010-07-17 1:03 ` [PATCH RFC 03/12] x86/ticketlock: Use C for __ticket_spin_unlock Jeremy Fitzhardinge
2010-07-20 15:38 ` [Xen-devel] " Konrad Rzeszutek Wilk
2010-07-20 15:38 ` Konrad Rzeszutek Wilk
2010-07-20 16:17 ` [Xen-devel] " Jeremy Fitzhardinge
2010-07-20 16:17 ` Jeremy Fitzhardinge
2010-08-06 17:47 ` [Xen-devel] " H. Peter Anvin
2010-08-06 17:47 ` H. Peter Anvin
2010-08-06 20:03 ` Jeremy Fitzhardinge [this message]
2010-08-06 20:03 ` Jeremy Fitzhardinge
2010-07-17 1:03 ` [PATCH RFC 07/12] x86/spinlocks: replace pv spinlocks with pv ticketlocks Jeremy Fitzhardinge
2010-07-17 1:03 ` [PATCH RFC 10/12] x86/pvticketlock: keep count of blocked cpus Jeremy Fitzhardinge
2010-08-03 8:32 ` Peter Zijlstra
2010-08-03 8:32 ` Peter Zijlstra
2010-08-03 9:44 ` Nick Piggin
2010-08-03 15:45 ` Jeremy Fitzhardinge
2010-08-03 15:45 ` Jeremy Fitzhardinge
2010-07-17 1:03 ` [PATCH RFC 09/12] xen/pvticketlock: Xen implementation for PV ticket locks Jeremy Fitzhardinge
2010-09-26 11:39 ` Srivatsa Vaddagiri
2010-09-26 22:34 ` Jeremy Fitzhardinge
2010-09-26 22:34 ` Jeremy Fitzhardinge
2011-01-18 16:27 ` Srivatsa Vaddagiri
2011-01-19 1:28 ` Jeremy Fitzhardinge
2010-07-17 1:03 ` [PATCH RFC 05/12] x86/ticketlock: make __ticket_spin_lock common 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=4C5C6A74.1050106@goop.org \
--to=jeremy@goop.org \
--cc=JBeulich@novell.com \
--cc=avi@redhat.com \
--cc=hpa@zytor.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@suse.de \
--cc=peterz@infradead.org \
--cc=xen-devel@lists.xensource.com \
/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.