RE: [Xen-devel] SMP Guest Proposal RFC

["Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>]

> Attached is a proposal authored by Bryan Rosenburg, Orran 
> Krieger and Ryan Harper.  Comments, questions, and criticism 
> requested.

Ryan,

Much of what you're proposing closely matches our own plans: It's always
better that a domain have the minimum number of VCPUs active that are
required to meet its CPU load, and gang scheduling is clearly preferred
where possible. 

However, I'm convinced that pre-emption notifcations are not the way to
go: Kernels typically have no way to back-out of holding a lock early,
so giving them an active call-back is not very useful.

I think its better to have a counter that the VCPU increments whenever
it grabs a lock and decrements when it releases a lock. When the
pre-emption timer goes off, the hypervisor can check the counter. If its
non zero, the hypervisor can choose to hold-off the preemption for e.g.
50us. It can also set a bit in another word indiciating that a
pre-emption is pending. Whenever the '#locks held' counter is
decremented to zero, the pre-emption pending bit can be checked, and the
VCPU should imediately yield if it is.

An alternative/complementary scheme would be to have each lock able to
store the number of the VCPU that's holding it. If a VCPU finds that a
lock is already taken, it can look in the shared info page to see if the
VCPU that's holding the lock is actually running. If its not, it can
issue a hypervisor_yield_to_VCPU X hypercall and avoid further spinning,
passing its time slice to the VCPU holding the lock. 

Anyhow, good stuff to discuss next week.

Best,
Ian







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