| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] SMP Guest Proposal RFC
> 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
|
|
|
| |
|
Home