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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

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.

 -George

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