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] Linux spin lock enhancement on xen

To: "Mukesh Rathor" <mukesh.rathor@xxxxxxxxxx>
Subject: Re: [Xen-devel] Linux spin lock enhancement on xen
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Tue, 17 Aug 2010 08:53:32 +0100
Cc: "Xen-devel@xxxxxxxxxxxxxxxxxxx" <Xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 17 Aug 2010 00:54:03 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20100816183357.08623c4c@xxxxxxxxxxxxxxxxxxxx>
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: <20100816183357.08623c4c@xxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 17.08.10 at 03:33, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:

A mere vcpu_kick()+do_yield() seems pretty simplistic to me - if the
current vCPU still has higher priority than the one kicked you'll achieve
nothing. Instead, I think you really want to offer the current vCPU's
time slice to the target, making sure the target yields back as soon as
it released the lock (thus transferring the borrowed time slice back to
where it belongs).

And then, without using ticket locks, you likely increase unfairness
(as any other actively running vCPU going for the same lock will
have much better chances of acquiring it than the vCPU that
originally tried to and yielded), including the risk of starvation.

Still, I'm glad to see we're not the only ones wanting a directed
yield capability in Xen.

>+struct sched_yield_to {
>+    unsigned int version;
>+    unsigned int vcpu_id;

Why do you need a version field here, the more as it doesn't
appear to get read by the hypervisor.


Xen-devel mailing list