|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] Linux spin lock enhancement on xen
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
|
|
|
|
|