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:47:13 +0100
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>
Delivery-date: Wed, 15 Apr 2009 08:47:41 -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=S1L+jyqMGuvhBuo3U4dSgNrBJ6vIWzKb8hukXnrw18I=; b=hIhNaJNDoji56GTGm/vcsHE394iea5z07TymLDzqegWxz3zFkwpDGAj37Ubj/owTCa XWzKw/sJ/jdJ8CpSSlm7tKo4PnIGs4gtNq4bh/26ehaWirCS+4mz1AEySvRhgIkfE6yo XtNO/D6hlTCdJUzgitHrdTsawvfDR1Cq5QgyM=
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=isy+jS5s7BPdaBljnvmrfuzM0fGxa+g8OvtR30GYbGOCckTgHluw6fYMlgMImqy08c wN3HEL1n7d7Dyl8DLgwST62gbpsN+aihjHsoNPQbmD60qRdSQ1qWwdwrmXU28bwXa0xJ +6ySnMExViRjdxoLN5K+DiQI3fq/ZDCvBwqRE=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <0A882F4D99BBF6449D58E61AAFD7EDD61036AB19@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> <4FA716B1526C7C4DB0375C6DADBC4EA34172EC1C9C@xxxxxxxxxxxxxxxxxxxxxxxxx> <49DF7FBF.9060209@xxxxxxxx> <0A882F4D99BBF6449D58E61AAFD7EDD61036AB19@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
2009/4/11 Tian, Kevin <kevin.tian@xxxxxxxxx>:
> the normal name for this is Turbo Boost. However it'd be difficult
> for software to accounting for extra cycles gained from overclock,
> as whether boost actually happens and how much cycles can
> be boosted are completely controlled by hardware unit.

>From the context, it sounded like Jeremy was saying that if we expose
a whole socket to a guest, then the guest can try to schedule things
either to take advantage of multiple cores or to take advantage of
Turbo Boost.  (i.e., punt the Turbo Boost performance optimization to
the guest, just as we could punt the hyperthreading problem to the

In any case, even if we can't control it, we may be able to either do
some estimates (i.e., we expect this core to run at about 120%).
There will probably be some performance counters that we could use to
estimate how much "boost" a VM actually got and deal with credits
accordingly... but that's yet another level of complication.  I'll put
it in the list of things to look at, and we'll see how far we get.


Xen-devel mailing list

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