On 12/01/2010 07:29 PM, Srivatsa Vaddagiri wrote:
> > > A plain yield (ignoring no-opiness on Linux) will penalize the > > > running guest wrt other guests. We need to maintain fairness. Avi, any idea how much penalty are we talking of here in using plain yield? If that is acceptable in practice, I'd prefer we use the plain yield rather than add any more sophistication to it ..
The first issue with plain yield is that it's a no-op unless some ioctl is enabled. It's simply not very meaningful for CFS. That's why the current PLE implementation uses sleep() (which is incredibly sucky in another way).
Even if we do get yield() to work, giving up a timeslice will cause a contending guest to lose way more than its fair share. Consider a lock that is held for 100us every 500us; if each time we detect contention we give up a 3ms timeslice, the guest will grind down to a halt while other guests will happily use its timeslice. With directed yield, the guest continues to run; and any excess time we donated to a vcpu is preserved.
> The Xen paravirt spinlock solution is relatively sane, use that. > Unmodified guests suck anyway, there's really nothing much sane you can > do there as you don't know who owns what lock. Hopefully we don't have to deal with unmodified guests for too long. Till that time, plain yield() upon lock-contention seems like the best option we have for such unmodified guests.
We will have to deal with unmodified guests forever. Both older Linux and Windows.
-- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
