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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: George Dunlap
>Sent: 2009年4月15日 23:56
>
>2009/4/11 Tian, Kevin <kevin.tian@xxxxxxxxx>:
>> The major worry to me is added complexity by exposing such sibling
>> pairs to guest. You then have to schedule at core level for that VM,
>> since the implication of HT should be always maintained or else
>> reverse effect could be seen when VM does try to utilize 
>that topology.
>> This brings trouble to scheduler. Not all VMs are guest SMP, and
>> then the VM being exposed with HT is actually treated unfair as one
>> more limitation is imposed that partial idle core can't be used by it
>> while other VMs is immune. Another tricky part is that you have to
>> gang schedule that VM, which is in concept fancy but no one has
>> come up a solid implementaion in real.
>
>I think gang scheduling with this limited scope (a hyper-pair to be
>scheduled on a hyper-pair) should be a lot easier than the general
>case.  In any case, as long as we assign and deduct credits
>appropriately, a threaded VM shouldn't have a disadvantage compared to
>a single-thread VM.
>

Could you elaborate more about what's being simplified compared to
generic gang scheduling? I used to be scared by complexity to have 
multiple vcpus sync in and sync out, especially with other 
heterogeneous VMs (w/o gang scheduling requirement). It's possibly
simpler if all VMs in that system are hyper-pair based... :-)

Thanks
Kevin

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