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] Ticket spinlocks and MP guests

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, "Espen Skoglund" <espen.skoglund@xxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] Ticket spinlocks and MP guests
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Fri, 15 Feb 2008 17:12:43 +0800
Delivery-date: Fri, 15 Feb 2008 01:14:42 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C3DB0362.14056%Keir.Fraser@xxxxxxxxxxxx>
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: <D470B4E54465E3469E2ABBC5AFAC390F024D8F7C@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C3DB0362.14056%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-topic: [Xen-devel] Ticket spinlocks and MP guests
>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx] 
>Sent: 2008年2月15日 16:53
>On 15/2/08 08:42, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>>> You would of course spin for a while and only then sleep.
>>> That's a standard
>>> mutex implementation trick.
>> I'm not sure how to define 'a while', since even for same critical
>> section the spin cycles varies at different point. You always risk
>> adding more overhead than a normal spin loop. But well, it depends
>> on how frequent forementioned case may occur, and the gain
>> of pv'ed spinlock may be larger than overhead it causes.
>You could certainly end up in the situation that the lock 
>becomes available
>just after you decide to sleep, no matter what spin threshold 
>you choose.
>It's a balance of probabilities: e.g., if you spin for 1us, what is the
>probability distribution of remaining wait time? If the lock-holder is
>preempted then you are likely to spin for ages. That, coupled with most
>spinlock regions in the kernel being very fast, means that we 
>wouldn't need
>to be very smart to filter out the former cases without 
>hurting performance
>in the latter. The distribution of waits will be very 
>obviously bimodal.
> -- Keir

Yes, that makes sense. It can be extended to cover ticket spinlock
usage, like forcing sleep if smaller ticket is already in, and only 
wake vcpu with 'next' ticket at unlock, etc. :-)


Xen-devel mailing list