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: "Keir Fraser" <keir.xen@xxxxxxxxx>, "Juergen Gross" <juergen.gross@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Performance difference between Xen versions
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Mon, 02 May 2011 08:23:37 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 02 May 2011 00:24:26 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C9E41092.170DB%keir.xen@xxxxxxxxx>
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: <4DBE41C9.1010409@xxxxxxxxxxxxxx> <C9E41092.170DB%keir.xen@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 02.05.11 at 08:41, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> On 02/05/2011 06:31, "Juergen Gross" <juergen.gross@xxxxxxxxxxxxxx> wrote:
>>>> Is there any easy explanation for this? Both Xen versions are from SLES
>>>> (SLES11 or SLES11 SP1).
>>> I think cpufreq handling was off by default in 3.3, and is on by
>>> default on 4.0. Try turning this off, or using the performance
>>> governor.
>> Jan, you got it! With cpufreq=none Xen 4.0 has more or less the same numbers
>> as 3.3. Now I wonder why the default is so much slower. I looks as if the
>> hypervisor would run at a lower speed. I can't believe it should behave like
>> that!
> It runs at lower frequency unless your test offers sufficient load over a
> long enough time period. Short microbenchmarks are probably finished before
> the frequency governor can react.

Correct. I generally found the default threshold of the ondemand
governor nor very suitable for optimal performance of short lived
jobs, and boot all of my systems with "cpufreq=xen:ondemand,threshold=20".


Xen-devel mailing list