Re: credit scheduler and HYPERVISOR_yield()

[Emmanuel Ackaouy <ackaouy@gmail.com>]

On Oct 9, 2007, at 15:22, George Dunlap wrote:
> What this means in the case of a yield(), unfortunately, is that If a
> given vcpu is the only vcpu on its processor with credits left, all it
> can do is burn up its extra credits spinning or calling yield() to no
> effect.
>
> A simple option would be, for the credit scheduler, to temporarily
> reduce the priority from TS_UNDER to TS_OVER.  This will cause it to
> actually yield if there's any other vcpus that can run.  The next time
> accounting is done, the priority will be reset, and it should get more
> time because of the time it's given up.

Temporarily changing the priority to TS_OVER strikes me as a
reasonable idea. However, changing it for an average of half of
the accounting period (1/2 100ms = 50ms) is hardly "temporary".
A VCPUs that would call yield() more than once every 50ms or
so -- which isn't unreasonable -- would never be able to run at
TS_UNDER. That would totally distort accounting fairness for
users of yield(). Maybe something more in the temporary spirit
of the TS_BOOST priority (but lower not higher than TS_UNDER)
would be better?

It may be worthwhile to consider if yield() can be replaced with
more intelligent mechanisms for VCPU synchronization of SMP
guests. In the case of ACKed IPIs for example, if all target VCPUs
are not running at the time of the IPI initiation, it might be a good
idea to put the source to sleep until all targets have ACKed.
If all target VCPUs are running though, I suspect things will work
best if the IPI initiator does not yield at all.