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

Luca
2007-08-22T17:23:17Z

On 8/22/07, Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 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.

Luca