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

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

At 17:11 +0100 on 24 Aug (1282669892), George Dunlap wrote:
> It depends on the implementation.  The Citrix guest tools do binary
> patching of spinlock routines for w2k3 and XP; I believe they spin for
> 1000 cycles or so.  The viridian enlightenments I believe would yield
> immediately.

IIRC the Viridian interface includes a parameter that the hypervisor
passes to the guest to tell it how long to spin for before yielding. 

>  I think the pause instruction causes a yield immediately
> as well.

This is where the PLE hardware assist comes in - it effectively does the
same as the Viridian interfaces by counting PAUSEs.

FWIW (and I am defintely not a scheduler expert) I'm against anything
that gives a priority boost to a domain's VCPUs based on perceived
locking behaviour, and in favour of keeping things dead simple.
Targeted scheduler "improvements" have bitten us more than once.  When
George's scheduler regression tests can give us a more rounded picture
or the overall effect of scheduler tweaks (esp. on fairness) maybe that
will change.

Cheers,

Tim.

> Yielding immediately when the host is not overloaded is actually
> probably not optimal: if the vcpu holding the lock is currently
> running, it's likely that by the time the vcpu makes it to the
> scheduler, the lock it's waiting for has already been released.
> (Which is part of the reason it's a spinlock and not a semaphore.)
> 
> > And so I do with this. Apart from suspecting fairness issues with
> > your yield_to proposal (as I wrote), my point just is - we won't
> > know if a "complicated" solution outperforms a "simple" one if we
> > don't try it.
> 
> Are you volunteering? :-)
> 
>  -George
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, XenServer Engineering
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

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