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

To: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] Linux spin lock enhancement on xen
From: Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
Date: Tue, 17 Aug 2010 18:58:16 -0700
Cc: "Xen-devel@xxxxxxxxxxxxxxxxxxx" <Xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 17 Aug 2010 19:02:02 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4C6A5C1C02000078000104D1@xxxxxxxxxxxxxxxxxx>
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>
Organization: Oracle Corporation
References: <20100816183357.08623c4c@xxxxxxxxxxxxxxxxxxxx> <4C6A5C1C02000078000104D1@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, 17 Aug 2010 08:53:32 +0100
"Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:

> >>> 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).

True, that is phase II enhancement.

> 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.

Please see other thread on my thoughts on this.

> 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.

No reason, just forgot to remove it.

thanks,
Mukesh


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel