Re: credit scheduler and HYPERVISOR_yield()

[Samuel Thibault <samuel.thibault@xensource.com>]

Hi,

George Dunlap, le Mon 15 Oct 2007 13:26:06 +0100, a écrit :
> I can't really think of a situation where
> "yield-to-other-cpus-that-haven't-used-all-their-credits-yet" is
> particularly useful.  Can you think of an example?

That could actually be the counter part of "yield-I-really-mean-it":
- vCPU0 yields-really-means-it so as to hopefully schedule vCPU1
- vCPU1 realizes why it got scheduled, does the needed urging job.
- vCPU1 "yields-to-other-cpus-thatblabla", for letting Xen know it
  finished its urging job and usual priorities can be taken into account
  again.
- vCPU0 gets scheduled again because it actually had bigger priority.

> Here are some random ideas:
> * Expose to the guest, via the shared-info page, which vcpus are
> actively scheduled or not.

That could be useful, but one can't safely rely on it, since it may
change asynchronously.

> * Implement some kind of a yield or block primitive, like:
> + yield to a specific vcpu (i.e., the one holding the lock you want)

That should be quite fine.  Xen could use it as a strong scheduling
hint. If scheduling that vCPU immediately would break some quota rules
for instance, Xen could still remember that it shouldn't reschedule the
calling vCPU before having scheduled the target vCPU at least once.

> + block with a vcpu mask.  The vcpu will then be blocked until each of
> the vcpus in the mask has been scheduled at least once.

That could be also called yield_to_vcpus actually.

Samuel