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] Performance difference between Xen versions

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Subject: Re: [Xen-devel] Performance difference between Xen versions
From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
Date: Fri, 06 May 2011 15:49:13 +0200
Cc: Keir Fraser <keir.xen@xxxxxxxxx>, Keir Fraser <keir@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Delivery-date: Fri, 06 May 2011 06:50:14 -0700
Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=juergen.gross@xxxxxxxxxxxxxx; q=dns/txt; s=s1536b; t=1304689756; x=1336225756; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=8EO7uFIzlYMyjvn+5xZctliTKaBx+zSL+mJR0u5J1uc=; b=DX37BQi4AUVkJ2Q9OOG2yx89D0uSl7y7SQVUKuLYGpPxMoFmIMif01bx QTKt2mUyYeYuDbZuUND75sKnSDbAA4M7iMZnhXfehOh5eFBD86nA6g7gy jFgW+43pf5bMo4D+gxI0Wka8AHC0q31RD+9m33xSKtRe7W0rUwdgb+vwi y8YwyiExq7tYQ20C26/cywKF9nMlcHQGZA7XwaRFY/p3i3J3TBxxbf0d+ b3MQh+9SBUKzrwh4TxU1QBTQDLvre;
Domainkey-signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=sPgvCtb6V4xTMSTnVEERRWOwkM4fe9mazg4/tmyAy2Ln/HlU3GUtTsXN KD00KhDiIsMsMojFeTEjqewAFYlSYfdPPrj31UNUNC9IDq+eduAB3wRPl ILn06JvmdW6Tgp7ViWskhaxApaH4XThJ1Z0zccyQO3+05QNuDQlScWRCQ hfWpoeDEum99D+wQpwOGohBiyB08GjD4uBjx7eTq0F4Q/xEOtau+opWye Ig1PAISkO1D0HHzMfoVUZ+cg/H6R4;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <625BA99ED14B2D499DC4E29D8138F1505C885A8F53@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>
Organization: Fujitsu Technology Solutions
References: <4DBE6A1C.2040107@xxxxxxxxxxxxxx> <C9E42E8E.2CD9B%keir@xxxxxxx> <625BA99ED14B2D499DC4E29D8138F1505C885A8F53@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110402 Iceowl/1.0b2 Icedove/3.1.9
On 05/03/11 05:06, Tian, Kevin wrote:
From: Keir Fraser
Sent: Monday, May 02, 2011 4:49 PM

On 02/05/2011 09:23, "Juergen Gross"<juergen.gross@xxxxxxxxxxxxxx>  wrote:

On 05/02/11 10:15, Jan Beulich wrote:
On 02.05.11 at 10:00, Juergen Gross<juergen.gross@xxxxxxxxxxxxxx>
On the long run I'd like to make the cpufreq governor a feature of
the cpupool. This would enable an administrator of a large Xen
machine with a heterogeneous load to specify which domains should
run at full speed and which are allowed to save energy at the cost of
What do you think?
Certainly an interesting idea, with the question of how an
implementation of this would look like.
Let me do some research work first :-) I hope to make a proposal soon.
I think it's a good idea, and it should be quite possible to implement cleanly.

yes, this is a good direction. Actually there have been several papers around 
this topic
before. Basically it's a reasonable choice to inject higher level knowledge 
with VMM heuristics, as in virtualization or cloud we usually have an 
intelligent stack
which needs to understand many high level requirements/characteristics already. 

Okay, I think I understand the basic mechanisms of cpufreq stuff now :-)
I propose the following changes:

- Cpupools get a new parameter "cpufreq" which is similar to the hypervisor
  boot parameter. It is valid if the hypervisor is responsible for cpufreq
  handling (this excludes cases cpufreq=none and cpufreq=dom0-kernel)
- Cpupool0 is initialized with the boot parameter settings, new cpupools are
  created with the cpupool0 settings, they get their new cpufreq parameters
via libxl later (this avoids changing the interface for cpupool creation, I only
  need a new interface to set the cpufreq parameters for a cpupool, which
  can be used for changing the settings, too. This interface could take the
  cpufreq parameters as text string resulting in support of exactly the same
  parameters as the hypervisor).
- cpufreq_policy is only spanning multiple cpus of one cpupool (if at all). This
  requires a check for the max frequency to be set in a frequency domain
  if the frequency of a processor is changing. This is similar to the ondemand
  governor, but might cross cpufreq_policy boundaries.

Did I miss anything? Any other suggestions?


Juergen Gross                 Principal Developer Operating Systems
TSP ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@xxxxxxxxxxxxxx
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html

Xen-devel mailing list