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


[Xen-devel] Re: [patch 2/8] Implement always-locked bit ops, for memory

To: Christoph Lameter <clameter@xxxxxxx>
Subject: [Xen-devel] Re: [patch 2/8] Implement always-locked bit ops, for memory shared with an SMP hypervisor.
From: Zachary Amsden <zach@xxxxxxxxxx>
Date: Wed, 02 Aug 2006 18:18:04 -0700
Cc: akpm@xxxxxxxx, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Jeremy Fitzhardinge <jeremy@xxxxxxxxxxxxx>, Ian Pratt <ian.pratt@xxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, Chris Wright <chrisw@xxxxxxxxxxxx>, virtualization@xxxxxxxxxxxxxx, Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Delivery-date: Wed, 02 Aug 2006 18:18:33 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <Pine.LNX.4.64.0608021805150.26314@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: <20060803002510.634721860@xxxxxxxxxxxxx> <20060803002518.061401577@xxxxxxxxxxxxx> <Pine.LNX.4.64.0608021726540.25963@xxxxxxxxxxxxxxxxxxxxxxxxx> <44D144EC.3000205@xxxxxxxx> <Pine.LNX.4.64.0608021805150.26314@xxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20060516)
Christoph Lameter wrote:
Thats a good goal but what about the rest of us who have to maintain additional forms of bit operations for all architectures. How much is this burden? Are locked atomic bitops really that more expensive?

It needn't be all architectures yet - only architectures that want to compile Xen drivers are really affected. Perhaps a better place for these locking primitives is in a Xen-specific driver header which defines appropriate primitives for the architectures required? Last I remember, there were still some issues here where atomic partial word operations couldn't be supported on some architectures.

To answer your question, yes. On most i386 cores, locks destroy performance, and even unintentional use of a single locked operation in a critical path, on uncontended local memory, can have several hundred cycles downstream penalty. I accidentally used one once during context switch, and saw a 30% reduction in switch performance - on a modern processor.


Xen-devel mailing list

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