| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH RFC 03/12] x86/ticketlock: Use C for __ticket_spi
|
To: |
"H. Peter Anvin" <hpa@xxxxxxxxx> |
|
Subject: |
Re: [Xen-devel] [PATCH RFC 03/12] x86/ticketlock: Use C for __ticket_spin_unlock |
|
From: |
Jeremy Fitzhardinge <jeremy@xxxxxxxx> |
|
Date: |
Fri, 06 Aug 2010 13:03:00 -0700 |
|
Cc: |
Nick Piggin <npiggin@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Peter Zijlstra <peterz@xxxxxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>, Avi Kivity <avi@xxxxxxxxxx> |
|
Delivery-date: |
Fri, 06 Aug 2010 13:03:57 -0700 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<4C5C4AAB.3000606@xxxxxxxxx> |
|
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
|
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
|
List-post: |
<mailto:xen-devel@lists.xensource.com> |
|
List-subscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
|
List-unsubscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
|
References: |
<cover.1279328276.git.jeremy.fitzhardinge@xxxxxxxxxx> <f3622d39ae72573c586405ea6f1597eb39fc28d4.1279328276.git.jeremy.fitzhardinge@xxxxxxxxxx> <20100720153845.GA9122@xxxxxxxxxxxxxxxxxxx> <4C45CC02.7030603@xxxxxxxx> <4C5C4AAB.3000606@xxxxxxxxx> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.7) Gecko/20100720 Fedora/3.1.1-1.fc13 Lightning/1.0b2pre Thunderbird/3.1.1 |
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home