[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC] Scheduler work, part 1: High-level goals and interface.



George Dunlap wrote:
On Fri, Apr 10, 2009 at 6:19 PM, Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
This can probably be extended to Intel's hyper-dynamic flux mode (that may
not be the real marketing name), where it can overclock one core if the
other is idle.

Jeremy,

Did you mean we could expose an entire socket to a guest VM, so that
it could schedule so as to take advantage of the effects of Turbo
Boost, just as we can expose thread pairs to a VM and let the guest OS
scheduler deal with threading issues?

Yes, precisely. They're the same in that Xen concurrently schedules two (or more?) vcpus to the guest which have interdependent performance. One could imagine a case where a guest with a single-threaded workload gets best performance by being given a thread/core pair, running their work on one while explicitly keeping the other idle. Of course that idle core is lost to the rest of the system in the meantime, so the guest should get charged for both.

And some kind of small-scale gang scheduling might be useful for small SMP guests anyway, because their spinlocks and IPIs will work as expected, and they'll presumably get shared cache at some level.

   J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.