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] Does dom0 see all physical processors? (RE:[Xen-ia64-dev

To: "Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>
Subject: Re: [Xen-devel] Does dom0 see all physical processors? (RE:[Xen-ia64-devel] SAL INFO virtualization)
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Wed, 5 Apr 2006 15:20:40 +0100
Cc: Jimi Xenidis <jimix@xxxxxxxxxxxxxx>, Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, "Tian, Kevin" <kevin.tian@xxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Tristan Gingold <Tristan.Gingold@xxxxxxxx>, okrieg@xxxxxxxxxx, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 05 Apr 2006 07:20:38 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <516F50407E01324991DD6D07B0531AD51BCF50@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: <516F50407E01324991DD6D07B0531AD51BCF50@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On 5 Apr 2006, at 15:07, Magenheimer, Dan (HP Labs Fort Collins) wrote:

I believe ppc has "paravirtualized spinlocks" in their Linux
kernel, though even this won't necessarily help with a poorly
written SMP application.

No data, admittedly, but perhaps our good buddies at
Watson could comment?

IBM did some investigation into this a while back. The conclusion then was that, even in a microbenchmark somewhat contrived to try and indicate 'worst case' spinlock behaviour, the benefit of smarter spinlocks was negligible. Maybe the benchmark was bad, maybe there are other pathological worst cases out there that the benchmark did not represent, or maybe the smart spinlocks should have been smarter. Whatever: the numbers we have so far do not indicate that there's a problem to be solved, and these potential multi-processor optimisations have to be empirically driven because intuition is so frequently off the mark.

 -- Keir

Xen-devel mailing list