[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] credit scheduler and HYPERVISOR_yield()
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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |