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: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, Espen Skoglund <espen.skoglund@xxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Ticket spinlocks and MP guests
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Fri, 15 Feb 2008 08:52:50 +0000
Delivery-date: Fri, 15 Feb 2008 00:52:25 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <D470B4E54465E3469E2ABBC5AFAC390F024D8F7C@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AchvHZx52xVv2tsQEdyZRwAWy6hiGQAUAqPwAA+TMGsAAAamMAAAdQjMAAAAFCAAAJB2Mw==
Thread-topic: [Xen-devel] Ticket spinlocks and MP guests
User-agent: Microsoft-Entourage/
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

Xen-devel mailing list