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

[Jeremy Fitzhardinge <jeremy@goop.org>]

George Dunlap wrote:
> On Fri, Apr 10, 2009 at 6:19 PM, Jeremy Fitzhardinge <jeremy@goop.org> 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