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 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Performance overhead of paravirt_ops on nativeidentifie

To: "Jeremy Fitzhardinge" <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] Performance overhead of paravirt_ops on nativeidentified
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Fri, 15 May 2009 09:10:20 +0100
Cc: Nick Piggin <npiggin@xxxxxxx>, Xiaohui Xin <xiaohui.xin@xxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Xin Li <xin.li@xxxxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, Ingo Molnar <mingo@xxxxxxx>
Delivery-date: Fri, 15 May 2009 01:11:16 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4A0C58BB.3090303@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: <4A0B62F7.5030802@xxxxxxxx> <4A0BED040200007800000DB0@xxxxxxxxxxxxxxxxxx> <4A0C58BB.3090303@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Jeremy Fitzhardinge <jeremy@xxxxxxxx> 14.05.09 19:45 >>>
>Jan Beulich wrote:
>> Wouldn't a third solution be to use ticket spinlocks everywhere, i.e. 
>> eliminate
>> the current indirection, and replace it by an indirection for just the 
>> contention
>> case? As I view it, the problem for Xen aren't really the ticket locks by
>> themselves, but rather the extra spinning involved, which is of concern only
>> if a lock is contended. We're using ticket locks quite happily in our 
>> kernels,
>> with directed instead of global wakeup from the unlock path.
>Do you have a patch to illustrate what you mean?  How do you keep track 
>of the target vcpu for the directed wakeup?  Are you using the 
>event-poll mechanism to block?

A patch for the pv-ops kernel would require some time. What I can give you
right away - just for reference - are the sources we currently use in our 
kernel:
attached.

Jan

Attachment: spinlock.h
Description: Binary data

Attachment: spinlock.c
Description: Binary data

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>