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
testtimer.c
Description: Text Data
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home