WARNING - OLD ARCHIVES

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/
Xen

xen-devel

[Top] [All Lists]

[Xen-devel] Re: [RFC PATCH 05/35] Add sync bitops

To: Christoph Lameter <clameter@xxxxxxx>
Subject: [Xen-devel] Re: [RFC PATCH 05/35] Add sync bitops
From: Chris Wright <chrisw@xxxxxxxxxxxx>
Date: Tue, 9 May 2006 16:07:18 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Ian Pratt <ian.pratt@xxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, Chris Wright <chrisw@xxxxxxxxxxxx>, virtualization@xxxxxxxxxxxxxx, Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Delivery-date: 2006年5月09日 16:04:31 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <Pine.LNX.4.64.0605091555540.30338@xxxxxxxxxxxxxxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20060509084945.373541000@xxxxxxxxxxxx> <20060509085149.024456000@xxxxxxxxxxxx> <Pine.LNX.4.64.0605091555540.30338@xxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
* Christoph Lameter (clameter@xxxxxxx) wrote:
> On Tue, 9 May 2006, Chris Wright wrote:
>
> > Add "always lock'd" implementations of set_bit, clear_bit and
> > change_bit and the corresponding test_and_ functions. Also add
> > "always lock'd" implementation of cmpxchg. These give guaranteed
> > strong synchronisation and are required for non-SMP kernels running on
> > an SMP hypervisor.
>
> Could you explain why this is done and what is exactly meant with "always 
> looked"? Wh the performance impact?
The standard UP bitops are not atomic. But a UP guest may be on SMP
machine, and the bitmaps here are shared between guests. The always
locked means the lock prefix is not conditional on either UP build
(or smp alternatives patching), and memory barriers are in place.
There's no performance penalty unless you use them, as it's a new set
(somewhat similar to the bitops changes you were looking into). Although,
this is the simplest, with no multiplexing, simply new interface, synch_*.
Open to ideas here. Xen is another possible consumer of your bitops
changes.
thanks,
-chris
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>
Previous by Date: [Xen-devel] ParaGuest cannot see 30GB memory , pak333
Next by Date: [Xen-devel] Re: [RFC PATCH 05/35] Add sync bitops , Andi Kleen
Previous by Thread: [Xen-devel] Re: [RFC PATCH 05/35] Add sync bitops , Christoph Lameter
Next by Thread: [Xen-devel] Re: [RFC PATCH 05/35] Add sync bitops , Andi Kleen
Indexes: [Date] [Thread] [Top] [All Lists]

Copyright ©, Citrix Systems Inc. All rights reserved. Legal and Privacy
Citrix This site is hosted by Citrix

AltStyle によって変換されたページ (->オリジナル) /