[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Linux spin lock enhancement on xen



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

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.