Re: [Xen-devel] Re: [Xen-users] About profiling xen

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

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
>> CONFIG_HIGHRES_TIMERS enabled.
>>     
> 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.

    J

Attachment: testtimer.c
Description: Text Data

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel