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

[Luca <kronos.it@gmail.com>]

On 8/22/07, Luca <kronos.it@gmail.com> wrote:
> On 8/22/07, Avi Kivity <avi@qumranet.com> wrote:
> > Luca wrote:
> > >>> 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?
> > >>
> > >
> > > Nope:
> > >
> > > # CONFIG_NO_HZ is not set
> > > # CONFIG_HZ_100 is not set
> > > # CONFIG_HZ_250 is not set
> > > # CONFIG_HZ_300 is not set
> > > CONFIG_HZ_1000=y
> > > CONFIG_HZ=1000
> > >
> > > and I'm reading it from /proc/config.gz on the guest.
> > >
> >
> > Yeah, thought so -- so dyntick is broken at present.
>
> I see a lot of sub ms timer_settime(). Many of them are the result of
> ->expire_time being less than the current qemu_get_clock(). This
> results into 250us timer due to MIN_TIMER_REARM_US; this happens only
> for the REALTIME timer. Other sub-ms timers are generated by the
> VIRTUAL timer.
>
> This first issue is easily fixed; if expire_time < current time then
> the timer has expired and hasn't been reprogrammed (and thus can be
> ignored).
> VIRTUAL just becomes more accurate with dyntics, before multiple
> timers were batched together.
>
> > Or maybe your host kernel can't support such a high rate.
>
> I don't know... a simple printf tells me that the signal handler is
> called about 1050 times per second, which sounds about right.

...unless strace is attached. ptrace()'ing the process really screw up
the timing with dynticks; HPET is also affected but the performance
hit is not as severe.

Luca