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

Avi Kivity
2007-08-22T16:21:25Z

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.