This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH RFC 03/12] x86/ticketlock: Use C for __ticket_spi

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] [PATCH RFC 03/12] x86/ticketlock: Use C for __ticket_spin_unlock
From: "H. Peter Anvin" <hpa@xxxxxxxxx>
Date: Fri, 06 Aug 2010 10:47:23 -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 10:48:47 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4C45CC02.7030603@xxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100720 Fedora/3.1.1-1.fc13 Thunderbird/3.1.1
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.


H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>