[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.
>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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |