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 inte

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Subject: Re: [Xen-devel] [RFC] Scheduler work, part 1: High-level goals and interface.
From: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Date: Wed, 15 Apr 2009 16:56:15 +0100
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 15 Apr 2009 08:57:19 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=2XTt3iwFfYsuo0asccwA8ZVUctqh87J4ngY+LQf4WIg=; b=SA1sZlHixy5QpuhsCYVaHmJCxSMvlEw7sLAE9aOnISoY1vy35yk4eTpzHPMbXOr8rT XeVz5YenvPpjvrz6feu8G+CBmpUzuGXnBQnh+e32T5bHlwddMR5Fv5bOBW03hhrrpkFA MWTsS9/CH6IFLU6k7n0+yTumlVXnGk7fREXJY=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=K1en82fUpwCH8ypgj0duufFJNgidI3Lo2B2p/2eK0sPyH3dxcux1xJLXl8Vxy8dnUZ Van06gwIboRBHdho83Ja8GPXlKbfbIB18RPI1A6ULu9dTYk0Gf6qqx9F+5MjBtbY5iy7 KCCwEa8eU9nChEydZaNPiXSeXFXRdTiPtLY6Q=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <0A882F4D99BBF6449D58E61AAFD7EDD61036AB17@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>