This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [RFC] Scheduler work, part 1: High-level goals and interface.
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Thu, 16 Apr 2009 13:11:41 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 15 Apr 2009 22:12:26 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <de76405a0904150856p2419ad7ndfbbb26d0fbb2c6b@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <de76405a0904090858g145f07cja3bd7ccbd6b30ce9@xxxxxxxxxxxxxx> <49DE415F.3060002@xxxxxxxx> <0A882F4D99BBF6449D58E61AAFD7EDD61036A60D@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <49DF708F.6070102@xxxxxxxx> <0A882F4D99BBF6449D58E61AAFD7EDD61036AB17@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <de76405a0904150856p2419ad7ndfbbb26d0fbb2c6b@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acm94rcm+oW1pXAfQQuyHQ1yzOhz8wAbhtHg
Thread-topic: [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... :-)

Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>