[Qemu-devel] Re: [PATCH] qemu-kvm: response to SIGUSR1 to start/stop a VCPU (v2)

[Avi Kivity <avi@redhat.com>]

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