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] Re: [Xen-users] About profiling xen

To: Marco Tizzoni <marco.tizzoni@xxxxxxxxx>
Subject: Re: [Xen-devel] Re: [Xen-users] About profiling xen
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Thu, 01 Oct 2009 13:54:04 -0700
Cc: "Fajar A." <fajar@xxxxxxxxx>, Fasiha Ashraf <feehapk@xxxxxxxxxxx>, xen <xen-devel@xxxxxxxxxxxxxxxxxxx>, xen-users@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 01 Oct 2009 13:54:31 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <f9611b0f0910010035m40949fb3o5efe60469b4466b7@xxxxxxxxxxxxxx>
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: <196324.1267.qm@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <f9611b0f0909292333r7da0c616rbe53ca73a6ea512d@xxxxxxxxxxxxxx> <20090930063747.GG1434@xxxxxxxxxxx> <f9611b0f0909292340o6a53326aobcd87334d7cfaa6b@xxxxxxxxxxxxxx> <f9611b0f0909300045o55e22378xea270e9873471f1d@xxxxxxxxxxxxxx> <f9611b0f0909300206v53577d1cw300ff6092b8ffede@xxxxxxxxxxxxxx> <4AC3E889.6060407@xxxxxxxx> <f9611b0f0910010035m40949fb3o5efe60469b4466b7@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Lightning/1.0pre Thunderbird/3.0b3
On 10/01/09 00:35, Marco Tizzoni wrote:
> On Thu, Oct 1, 2009 at 1:23 AM, Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
>> Your clocksource is "xen", which is the best possible for a PV xen guest.
>> However, a clocksource is for measuring elapsed time, not triggering
>> timers.
> Why? How would you solve the problem of raising events at a fixed rate?

I'm not sure I follow you.  In the kernel, the clock*source* subsystem
is for measuring time: its used to implement gettimeofday, as well as
internal time accounting.  It isn't directly related to time events.

The clock*event* mechanism is all about setting up timers to raise events.

When running paravirtualized, we use Xen-specific versions of both.

>> Unfortunately there doesn't seem to be a /sys file to show the
>> current clockevent source in use, but if you have "xen" clocksource it's
>> almost certainly the xen clockevent.
>> However, this is only relevent if you have CONFIG_NO_HZ and
> I've tried both set/unset but nothing change.

Hm.  Its best to leave both enabled either way.

Try the attached program to get some info about how well timers are
working.  Compile with:
$ gcc -o testtimer testtimer.c -O -lrt

And test various results:
$ ./testtimer .1 > xen-0.1.out
$ ./testtimer .01 > xen-0.01.out
$ ./testtimer .001 > xen-0.001.out

You can plot the results with:
$ gnuplot
gnuplot> plot "xen-0.001.out" with lines

The plot is delta from the expected time, so the ideal is that they all
be 0.

On my system in dom0 I see about 10% overhead at .001 and .0005 sec, so
the timers aren't being quantized to 100/250Hz.


Attachment: testtimer.c
Description: Text Data

Xen-devel mailing list