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

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

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.

> I've also tried APC which was suggested by malc[1] and:
> - readings are far more stable
> - the gap between dynticks and non-dynticks seems not significant
>
>   
>> Can you verify this by running
>>
>>    strace -c -p `pgrep qemu` & sleep 10; pkill strace
>>
>> for all 4 cases, and posting the results?
>>     
>
> Plain QEMU:
>
> With dynticks:
>
> % time     seconds  usecs/call     calls    errors syscall
> ------ ----------- ----------- --------- --------- ----------------
>  57.97    0.000469           0     13795           clock_gettime
>  32.88    0.000266           0      1350           gettimeofday
>   7.42    0.000060           0      1423      1072 sigreturn
>   1.73    0.000014           0      5049           timer_gettime
>   0.00    0.000000           0      1683      1072 select
>   0.00    0.000000           0      2978           timer_settime
> ------ ----------- ----------- --------- --------- ----------------
> 100.00    0.000809                 26278      2144 total
>   

The 1072 select() errors are the delivered ticks (EINTR).  But why only
1000?  would have expected 10000 for a 1000Hz guest in a 10 sec period.

> HPET:
>
> % time     seconds  usecs/call     calls    errors syscall
> ------ ----------- ----------- --------- --------- ----------------
>  87.48    0.010459           1     10381     10050 select
>   8.45    0.001010           0     40736           clock_gettime
>   2.73    0.000326           0     10049           gettimeofday
>   1.35    0.000161           0     10086     10064 sigreturn
> ------ ----------- ----------- --------- --------- ----------------
> 100.00    0.011956                 71252     20114 total
>   

This is expected.  1 tick per millisecond.

> Unix (SIGALRM):
>
> % time     seconds  usecs/call     calls    errors syscall
> ------ ----------- ----------- --------- --------- ----------------
>  90.36    0.011663           1     10291      9959 select
>   7.38    0.000953           0     40355           clock_gettime
>   2.05    0.000264           0      9960           gettimeofday
>   0.21    0.000027           0      9985      9969 sigreturn
> ------ ----------- ----------- --------- --------- ----------------
> 100.00    0.012907                 70591     19928 total
>   

Same here.

> And KVM:
>
> dynticks:
>
> % time     seconds  usecs/call     calls    errors syscall
> ------ ----------- ----------- --------- --------- ----------------
>  78.90    0.004001           1      6681      5088 rt_sigtimedwait
>  10.87    0.000551           0     27901           clock_gettime
>   4.93    0.000250           0      7622           timer_settime
>   4.30    0.000218           0     10078           timer_gettime
>   0.39    0.000020           0      3863           gettimeofday
>   0.35    0.000018           0      6054           ioctl
>   0.26    0.000013           0      4196           select
>   0.00    0.000000           0      1593           rt_sigaction
> ------ ----------- ----------- --------- --------- ----------------
> 100.00    0.005071                 67988      5088 total
>   

kvm uses sigtimedwait() to wait for signals.  Here, an error (ETIMEDOUT)
indicates we did _not_ get a wakeup, so there are 1500 wakeups in a 10
second period.  Strange.  Some calibration error?

> HPET:
>
> % time     seconds  usecs/call     calls    errors syscall
> ------ ----------- ----------- --------- --------- ----------------
>  90.20    0.011029           0     32437     22244 rt_sigtimedwait
>   4.46    0.000545           0     44164           clock_gettime
>   2.59    0.000317           0     12128           gettimeofday
>   1.50    0.000184           0     10193           rt_sigaction
>   1.10    0.000134           0     12461           select
>   0.15    0.000018           0      6060           ioctl
> ------ ----------- ----------- --------- --------- ----------------
> 100.00    0.012227                117443     22244 total
>   

10K wakeups per second.  The code is not particularly efficient (11
syscalls per tick), but overhead is still low.

> Unix:
>
> % time     seconds  usecs/call     calls    errors syscall
> ------ ----------- ----------- --------- --------- ----------------
>  83.29    0.012522           0     31652     21709 rt_sigtimedwait
>   6.91    0.001039           0     43125           clock_gettime
>   3.50    0.000526           0      6042           ioctl
>   2.74    0.000412           0      9943           rt_sigaction
>   1.98    0.000298           0     12183           select
>   1.58    0.000238           0     11850           gettimeofday
> ------ ----------- ----------- --------- --------- ----------------
> 100.00    0.015035                114795     21709 total
>   

Same thing.

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

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


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/