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
