[Qemu-devel] Re: [kvm-devel] [PATCH 0/4] Rework alarm timer infrastrucure - take2

[Avi Kivity <avi@qumranet.com>]

Luca Tettamanti wrote:
> Il Wed, Aug 22, 2007 at 08:02:07AM +0300, Avi Kivity ha scritto: 
>   
>> Luca Tettamanti wrote:
>>
>>     
>>> Actually I'm having troubles with cyclesoak (probably it's calibration),
>>> numbers are not very stable across multiple runs...
>>>   
>>>       
>> I've had good results with cyclesoak; maybe you need to run it in
>> runlevel 3 so the load generated by moving the mouse or breathing
>> doesn't affect meaurements.
>>     
>
> This is what I did, I tested with -no-grapich in text console.
>
>   

Okay.  Maybe cpu frequency scaling confused it then.  Or something else?

>>> The guest is an idle kernel with HZ=1000.
>>>   
>>>       
>> Can you double check this?  The dyntick results show that this is either
>> a 100Hz kernel, or that there is a serious bug in dynticks.
>>     
>
> Ops I sent the wrong files, sorry.
>
> This is QEMU, with dynticks and HPET:
>
> % time     seconds  usecs/call     calls    errors syscall
> ------ ----------- ----------- --------- --------- ----------------
>  52.10    0.002966           0     96840           clock_gettime
>  19.50    0.001110           0     37050           timer_gettime
>  10.66    0.000607           0     20086           timer_settime
>  10.40    0.000592           0      8985      2539 sigreturn
>   4.94    0.000281           0      8361      2485 select
>   2.41    0.000137           0      8362           gettimeofday
> ------ ----------- ----------- --------- --------- ----------------
> 100.00    0.005693                179684      5024 total
>   

This looks like 250 Hz?  And a huge number of settime calls?

Something's broken with dynticks.

> % time     seconds  usecs/call     calls    errors syscall
> ------ ----------- ----------- --------- --------- ----------------
>  93.37    0.025541           3     10194     10193 select
>   4.82    0.001319           0     33259           clock_gettime
>   1.10    0.000301           0     10195           gettimeofday
>   0.71    0.000195           0     10196     10194 sigreturn
> ------ ----------- ----------- --------- --------- ----------------
> 100.00    0.027356                 63844     20387 total
>   

This is expected and sane.

> And this KVM:
>
> % time     seconds  usecs/call     calls    errors syscall
> ------ ----------- ----------- --------- --------- ----------------
>  42.66    0.002885           0     45527        24 ioctl
>  25.62    0.001733           0     89305           clock_gettime
>  13.12    0.000887           0     34894           timer_gettime
>   7.97    0.000539           0     18016           timer_settime
>   4.70    0.000318           0     12224      7270 rt_sigtimedwait
>   2.79    0.000189           0      7271           select
>   1.86    0.000126           0      7271           gettimeofday
>   1.27    0.000086           0      4954           rt_sigaction
> ------ ----------- ----------- --------- --------- ----------------
> 100.00    0.006763                219462      7294 total
>   

Similarly broken.  The effective frequency is twice qemu's.  I think we
had the same effect last time.

> % time     seconds  usecs/call     calls    errors syscall
> ------ ----------- ----------- --------- --------- ----------------
>  49.41    0.004606           0     59900        27 ioctl
>  24.14    0.002250           0     31252     21082 rt_sigtimedwait
>   9.65    0.000900           0     51856           clock_gettime
>   8.44    0.000787           0     17819           select
>   4.42    0.000412           0     17819           gettimeofday
>   3.94    0.000367           0     10170           rt_sigaction
> ------ ----------- ----------- --------- --------- ----------------
> 100.00    0.009322                188816     21109 total
>
>   

Similarly sane.


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.