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: Wed, 11 May 2011 08:23:36 +0200
Cc: Keir Fraser <keir.xen@xxxxxxxxx>, Keir Fraser <keir@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Delivery-date: Tue, 10 May 2011 23:24:16 -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=1305095019; x=1336631019; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=iZggeHgHRjSoKZyA30V9VfmKF5z5RLnv8G6fz7H5wgU=; b=hXKNlhUTPSbQfe9lWIb17uJJiSIzRuimMyOg0rTrCUpUB2nITxvls6of euD5UliY6tfYyRAZ2oot3YKkrCH0OrlCBd0LTzHyevO8hkntYD7aqtHGE MA9yRlMZhEAPH6nwIjk7gOvgWXrmgNXnkfPCDwrEaxVRz1IhtePM9tRe3 J89vtxFeo8Fe4w4pyVsvioVxVdDJjB7WKWL0lR+u6fjqbH30eA2BhtzXa HqjpTDK89foeUfcp6av/8XKc6Zb43;
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=E1IDdySUyQlBiUnGcJJmS/oKaCVw5t4kxuLkjHPcivzTjMz81wG618KD gtdPqJiKr7/GhswQlRw/MtkeYBXRBCCglWzXi4xmnmDnwXYSy7Ny2xzev 9ZQC5sPDHR8ZpfYu226YNKwS6kz0ZsywtyrOcJy8yAec0R8MafM5NSi29 /XQHTGJRxuHEeg39jttdp+OotdJ5JcUkso+jKS2R8Qiqdt65Prp96wP76 8W//aU+NWPiHMSxahxz+i4D945bWD;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <625BA99ED14B2D499DC4E29D8138F1505C8F0092E5@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> <4DC3FC59.3030303@xxxxxxxxxxxxxx> <625BA99ED14B2D499DC4E29D8138F1505C8F0092E5@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/11/11 08:08, Tian, Kevin wrote:
From: Juergen Gross [mailto:juergen.gross@xxxxxxxxxxxxxx]
Sent: Friday, May 06, 2011 9:49 PM

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>
On 05/02/11 10:15, Jan Beulich wrote:
On 02.05.11 at 10:00, Juergen
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
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 together 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 
    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?

I'm a little bit concerned whether cpupool is a good logical entity to bundle a
cpufreq policy. Basically the question is how do you define a cpupool, socket 
core based, or thread based? fully controllable by the admin?

Cpupools can be either configured by the admin or you can create
one cpupool per numa node (applicable to "big" machines only).

the reason why I ask this question is because a frequency scaling is 
a hardware attribute, and there may have some cross-dependencies among
different cores/threads within same package. In some implementations, e.g. you
may only have one core entering a lower frequency when all other cores within
same packages request to enter same or lower frequency. Such low level
dependency may be either managed by the firmware level automatically, or
fully coordinated by the cpufreq driver. But whatever model, the scaling 
may not be the same range as what user may want to define a cpupool.

It might be a good idea to add some information about frequency domains
to e.g. "xl info" output.

Possibly you may want to warn the user if the low level cpufreq dependency is
broken by the user-defined pool.

That's what I want to do.
Thanks for your thoughts.


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

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